kekekeks
+2

Заплатившим денюжку их уже выслали. В общий доступ выложат перед следующим дотнекстом. Есть запись докладов с первого трека, который вещался в общедоступном режиме.

kekekeks
+5

Тем более что можно выехать и пользоваться вконтаком из европы.

kekekeks
0

С браузером не сравнивали, но уже сейчас быстрее чем WPF на Windows на определённых сценариях (авалония поверх Direct2D начинается с 1:30).


И такой немаловажный момент. У нас (как во всех нормальных UI-тулкитах) есть виртуализация списков. В браузеры её не завезли и приходится изобретать криво работающие костыли. Соответственно на задачах "показать список на несколько тысяч элементов" работать будет шустрее, а памяти кушать на порядки меньше.

kekekeks
0

Ну у нас есть возможность статической подписки на уже зарегистрированные свойства, примерно вот так.

kekekeks
+1

1) Есть штатная тема, которую можно заменить на свою и в которой можно заменить цвета. Мимикрию под конкретные ОС пока не делали и наврятли будем делать до версии 1.0, если, конечно, не найдётся желающих этим делом заняться.
2) В качестве платного продукта оно бы неплохо зашло на всякого рода встраиваемых устройствах (Avalonia+Linux кушают порядка 100 мегабайт (x86, fbdev, наш каталог контролов в качестве объекта замера) против полугигабайтного аппетита Windows for IoT), а так же в качестве UI для игр. Там наблюдается некоторый голод в плане хорошего UI, так что можно было бы продавать за хорошую цену.

kekekeks
+3

Обычно выкладывают перед следующей конференцией. С декабрьской уже есть на ютубе.

kekekeks
0

#984. Когда определимся с как правильно и смержим — будет доступно в nuget-фиде с ночными сборками.

kekekeks
+1

Да, это явный баг с layout-ом у нас.

kekekeks
0

Я оригинальный CEFGlue использовал в WinForms и в целом был доволен. Порт для авалонии, насколько я знаю, делался по-возможности построчным копированием с WPF. Имеет смысл попробовать его погонять и попинать автора порта, если есть какие-то проблемы. Ну и следует понимать, что сейчас это не коробочное решение, а в какой-то мере конструктор "собери сам". Порт стал возможен только недавно после появления инфраструктуры WritableBitmap.

kekekeks
+1

Что-то с Layout-ом перемудрили. Если сделать вот так, то работает.


<Window xmlns="https://github.com/avaloniaui" Title="Test app" WindowState="Maximized" MinWidth="500" MinHeight="300">
    <Grid Name="MainGrid">
        <Button Content="Button text" VerticalAlignment="Top" HorizontalAlignment="Left" Margin="40,65,0,0" >
            <Border Width="201" Height="65">
                <TextBlock HorizontalAlignment="Center" VerticalAlignment="Center">Button Text</TextBlock>
            </Border>
        </Button>
    </Grid>
</Window>

Пойму, что там именно происходит и заведу issue.

kekekeks
+1

А весь XAML можно привести? Текстом.

kekekeks
+1

Авалония и формы — вещи ортогональные. В том плане, что у нас подход "рисуем всё сами и одинаково" (минус — гуй выглядит не "нативно", частично решается мимикрией через темы), а forms оборачивает нативные контролы (минусы — удачи с вёрсткой макета от дизайнера и весельем с реализацией хоть чего-то сложного или нестандартного для каждой из платформ в отдельности).


Каждый из подходов хорош для своих применений. Так что тут скорее будет интеграция одного с другим, а не наоборот. Причём на Android/iOS уже сейчас есть принципиальная возможность встраивать куски интерфейса на авалонии в forms, нужно только рендереры соответствующие написать. На досуге надо будет заняться

kekekeks
+1

Наша встроенная система работает на базе ReactiveExtensions. Альтернативный механизм биндингов прикручивается примерно так же как и к WPF-написанием этого самого механизма и реализацией соответствующего MarkupExtension.


Что именно имеется ввиду под "подпиской на изменения вызываемым кодом"?

kekekeks
+6

Будем его поддерживать. Он же по сути определяет перечень контролов и свойств, которые они должны иметь, не более того.

kekekeks
+3

Смотря для чего нужны. На десктопе сейчас разве что API для работы со шрифтами не хватает.


У нас пока в планах на 0.6 доделать deferred-рендеринг (который в отдельном потоке), переехать на Portable.Xaml (OmniXAML тормозной очень и хуже поддерживается), сделать нормальный превьювер для *nix-платформ и воткнуть его хотя бы в MonoDevelop, сделать уже наконец генерацию линуксовых пакетов и бандлов для OSX в один клик, сделать бакэнд на базе MonoMac.

kekekeks
+3
В "-vs-binding" мы указали, что Visual Studio должна вызывать задачу "webpack-script" (Которую студия теперь видит, благодаря установленному расширению) каждый раз перед построением проекта.

Это, вообще говоря, очень не хорошо, ибо вы таким образом сборку прибиваете к студии и к наличию установленного в ней расширения. Лучше в файл проекта добавить target:


<Target Name="AfterBuild">
    <Exec Command="npm run webpack-script" />
</Target>

См. более полный пример.

kekekeks
0
когда у него за спиной стоят страшные вражины, которые из-за плеча так и палят, какой же там пароль придумывается

Вроде как давно придумали галку "Показывать пароль"

kekekeks
+1

Да есть всякие в шарпе NancyFx и прочая хипстерщина. Но зачем они нужны, если сейчас завезли ASP.NET Core, который покрывает все возможные нужды? Раньше ещё отдельно WebAPI был, но его в основной аспнет интегрировали.

kekekeks
+9

В переводе с "мне-платят-за-1000-знаков" на русский: есть куча убунтоспецифичных-PPA со всяким разным софтом, пакеты из которых на дебиан ставить лучше не пытаться

kekekeks
+1

Вставку по средней кнопке в протоколе Нового Более Лучшего Дисплейного Сервера убрали, кстати. Во всяких федорах её сбоку изолентой прикрутили

kekekeks
+3

Компилятору сиренево, где брать эти типы, в mscorlib или в вашей вручную изготовленной dll-ке. Я так LINQ и async/await на .NET 2.0 заводил.

kekekeks
0

Ну вообще говоря можно и плагины писать и их подключать к проекту через nuget, мсбилд их подхватит. Всякий постпроцессинг сборок обычно так и работает.

kekekeks
0

Приезжайте в мае на .NEXT, там про неё слот будет.

kekekeks
0

Проблема в прожорливости таких решений. Наш каталог контролов после прокликивания всех вкладок кушает 42 мегабайта в private working set. И это на альфа-версии фреймворка, который никто особо не оптимизировал. Открываем в качестве единственной вкладки в хроме "хэлловорлд" на ангуларе (если кто возьмётся склепать аналог приложения для нормального сравнения — велкам), то спавнится в сумме 5 процессов, отъедающих больше сотни мегабайт в сумме.


И если при большом числе вкладок хром внутри себя ещё как-то нормально управляет ресурсами, то когда люди начинают делать "десктопные приложения", по факту перепаковывая сайт с браузерным движком, становится очень грустно.

kekekeks
+2

Ну за пределы 1% на десктопах ведь так и не вылезли.

kekekeks
+1
ЛПП. Ну или у вас 3.5 проекта, вы не пытаетесь ничего подключать через нугет, не пытаетесь пользоваться билдом с несколькими целевыми фреймворками итп. Любые изменения в составе солюшна, если он достаточно большой, приводят к подвисаниям на десятки секунд. Это при выключенном решарпере. Райдер на том же самом солюшне себе такого не позволяет.
kekekeks
+2
В 2017-ой многие вещи замедлились, из-за этого дополнительно лезут проблемы у расширений. Например, обход дерева зависимостей через [Reference::SourceProject](https://msdn.microsoft.com/en-us/library/aa984592(v=vs.71).aspx), на достаточно большом солюшне теперь занимает секунды против миллисекунд на 2015-ой, позавчера полдня убил на переписывание отслеживалки этого дела.
kekekeks
0
Ну вот эти «встраиваемые устройства» с .NET либо хотят 512 мегабайт памяти, либо используют микрофреймворк, на котором ничего толком нет.
kekekeks
0
Windows for IoT хочет 256 мегабайт оперативки. 512 для отрисовки хэлло ворлда на UWP.
Для сравнения авалония при отрисовке в фреймбуфер кушает порядка сотни. На 32-битном арме это ужмётся где-то до 70. Ну и системный линуксовый хлам скушает мегабайт 20. Но это всё пока на уровне альфы, да.
kekekeks
0
хотя кто мешает нормально в native компильнуться

Отсутствие нормального нативного компилятора. corert только с месяц назад перестал падать на Console.ReadKey

kekekeks
0
Вообще говоря в Mono есть худо-бедно работающая реализация Windows.Forms. Так что не то чтобы совсем гвоздями к WinAPI прибито.
kekekeks
0
А чего им договариваться. Их дело дать фреймбуфер, куда этот гуй рисовать. А то наплодили всяких гайдлайнов и изображают из себя невесть что. Почти как провайдеры, которые думают, что они не просто труба в интернет.
kekekeks
0
Откуда информация про переезд? GtkSharp работает сейчас только поверх Mono (технически можно портировать), а Xamarin.Mac гвоздями приколочен к патчам в моновском рантайме для поддержки интеграции с ObjC.
kekekeks
+3
Попробуйте в 2017-ой студии открыть солюшн с десятком NETStandard/NETCore-проектов, которые друг на друга ссылаются и при этом тянут кучу разного хлама с нугета. Узнаете, что такое отсутствие скорости.
kekekeks
+1
Эм. Вообще говоря на Windows работает поверх обычного .NET. На .NET Core переехать не может по причине того, что под него нет GTK#. Ну и на макоси они, вроде, что-то используют от Xamarin.Mac, а тот требует патченого моновского рантайма для работы.
kekekeks
+4
Ну вообще MonoDevelop (aka Xamrin Studio aka Visual Studio for Mac) — вполне себе кроссплатформенная IDE, написанная целиком .NET. По уровню до фич решарпера, конечно, не дотягивает, но рослином пользоваться в состоянии.
kekekeks
+1
Для штуки типа коммерческой IDE проект ещё не готов. Нет таких банальных вещей как API информации о шрифтах, да и вообще в целом куча шероховатостей. Плюс из-за проблем с разработкой не-на-windows (кроме райдера нормальных IDE просто нет, а райдер не умеет в отладку, да и плагин с автокомплитом и preview xaml под него соорудим не скоро, ибо кроме меня этим заниматься некому) вылезают платформозависимые косяки. В итоге когда начинают портировать штуки типа AvalonEdit, вылезают косяки типа этого: