Comments 29
т.е. если это компания стартап, которой нужно какой-то пульт от своего саса завернуть под десктоп — они юзают электон.
Если уже надо сделать качественно и без дропов — пишут натив.
Чем этот фреймворк отличается выгоднее от электрона, который позволяет из говна и палок собрать работающее решение, и есть ли в нем надежность натива?
По всей видимости оно вполне себе пригодно как встраиваемое решение для игр, благо рендерится самостоятельно средствами OpenGL.
Ну и я понимаю, что просто так и сразу люди не перейдут на эту технологию. Изначально, фреймвок в некоторой степени рассматривался в применении программистами бэк-энда, которые никак не связаны с фронтом, но в силу некоторых обстоятельств (рабочих, либо просто по желаю) захотели некоторый бэк-энд обернуть в GUI, но без потерь во времени и преодоления порога вхождения при изучении любой современной GUI системы. Другими словами целью было создать систему GUI с максимально низким порогом вхождения.
1) Что с разметкой? Всё кодом? Если есть нормальная разметка, то есть ли к ней визуальный дизайнер/превьювер?
2) Как обстоят дела с data binding и прочими MVVM?
3) Есть ли виртуализация списков?
Если ничего этого нет, то можно с тем же успехом взять GTK#/QML.NET.
Далее, у вас указано, что оно базируется на glfw. Как обстоят дела с непрямоугольными векторными элементами интерфейса типа кривых безье? Все векторные иконки сейчас на них.
2) Система, похожая на data binding (WPF) сейчас в разработке, проектируется наиудобнейший подход, но пока до релиза далеко
3) То же самое как во втором пункте
По поводу произвольных фигур — можно любую фигуру создать и использовать в интерфейсе, но нужно ее предоставить в триангулированном виде. Класс для работы с кривыми безье тоже есть, но в силу его незаконченности пока не доступен в текущем билде.
Будете заниматься разметкой — гляньте на https://github.com/kekekeks/XamlIl Мы его сейчас вкручиваем для компиляции XAML-а билд-таской в MSIL. В итоге после сборки в отладчике это выглядит примерно вот так:
Ваши графы объектов, где только контролы и подписки на их события, оно по идее должно уметь грузить чуть ли не из коробки.
но нужно ее предоставить в триангулированном виде
Ну вот триангуляция самопересекающихся полигонов с кривыми безье — это вообще говоря то самое место, где собака порылась.
Mac OS X же вообще запрещает создавать мультиоконные приложения, ибо требует, чтобы GUI был запущен только в главном потоке приложения.
Я не знаю, что именно у вас там за ограничения, но мы вообще успешно рисуем в несколько окон с одного NSOpenGLContext. Есть подозрение, что вы пытаетесь использовать OpenGL на виртуалке, в таком случае случаются знатные спецэффекты.
А IDE какое? Своё или интегрируется в студию? А когда появится визуальный редактор форм — то где он будет?
По поводу редактора. Первая версия планируется в виде отдельного приложения (наподобие JavaFX Scene Builder), которое будет синхронизироваться с открытым проектом в любой выбранной IDE.
Я так понял мне, как интегратору UI в приложения еще один стандарт разметки изучать?
Какие гарантии что вы не развалитесь через год и все мои знания не превратятся в пыль?
Вон Flutter на носу, его бы осилить.
У товарища kekekeks в этом плане более перспективнее всё. XAML это и платформа MS и Xamarin и Noises под Unity 3D/unreal. В случае если авалонию забросят, знания и опыт, которые я копил годами найдут нишу применения. Хотя, пользуясь случаем, поругаю и авалонию, за придумывание велосипедов а-ля кастомные биндинги и проперти, отказ от авалонии в одном из проектов был как раз по причине что не WPF like код, слишком много времени нужно потратить на портацию, проект большой, было предложение «давайте попробуем, сколько стоит?»
Сейчас, мне самой перспективным под кросплатформенный .net видится связка Unity3D + Noesis GUI. На нем я с толкача несколько старых WPF UI завел вообще без проблем.
Noesis это шустрый привычный XAML, а Unity3D решение всех проблем с кросплатформенностью и производительностью. Производительность это важно. Добавляйте в свои GUI фреймворки примеры, где в списках по миллиону записей, где шарики на фоне генерируются анимациями, летают и после пролета уничтожаются, чтобы я смотрел на загрузку оперативной памяти/процессора и ЗАХОТЕЛ пользоваться фрейморком для GUI.
В свое время когда с WPF портировал один умный дом на UWP (кстати, всего месяц убил) я просто визжал от счастья, насколько быстро там все летало. «Наконец-то полноценный мультитач, плавный зум и шустрые анимации» — думал я.
А без этого вообще не понятно «А вдруг не потянет?» Тратить 3-5 месяцев работ на энтузиазме? времена не те. Глядя на простецкий пример в посте, мне кажется это шагом назад.
Noesis сначала тоже шли по пути «а придумаем ка мы свой WPF с блекджеком и сами знаете кем» 3 года назад я посмотрел на них и бросил, но сейчас, на поводу у сообщества они идут праведным путем, переписывая все под WPF like, чтобы такие как я могли максимально быстро перейти на платформу. (хотя UWP like мне нравился бы еще больше) У них даже сам UI отдельно можно в Blend как WPF проект править и запускать Win приложением на тесты, ИМХО — супер. Лучше и быть не может.
Пока жду что там по .netCore у Unity3D, мне кажется т.к. они смогли перейти на .net framework 4, отказались от mono develop, все предпосылки к этому есть. Также жду, когда WPF выложат в OpenSource полностью, чтобы Noesis закрыла то, с чем у них проблемы (бихейворы например) не критично, но полный WPF like + .net4/core даст им преимущество вида «а не попробовать ли мне быстренько портировать вот этот телериковский контрольчик». Розовые мечты конечно, но 2020й год покажет. В этой связке другие проблемы беспокоят, которые уже упоминали в комментариях. MVVM, виртуализация, связка с OS (нотификации там всякие из трея) т.е. не сам GUI, а что сразу за ним. Посему на авалонии крест даже и не думал пока ставить, в отличии от того же Xamarin.
P/S Не нравится XAML — есть армия верстальщиков на HTML.
Я вас прекрасно понимаю, так как сам не раз оказывался в ситуации, когда выбор стека технологий не являлся очевидным для проекта и некоторые его модули в последствии были переписаны полностью, ибо выбранная технология для них безнадежно устарела и заброшена, либо была перспективной, но так же заброшенной. Так же случалось и со знаниями, знания и опыт есть, а применить негде.
Пока вам предлагаю просто последить за SpaceVIL. В ближайшее время я проект забрасывать не собираюсь, ибо он еще не готов, а я не люблю оставлять проекты незавершенными.
не WPF like код, слишком много времени нужно потратить на портацию
У нас сейчас есть план дождаться полной выкладки WPF в опенсорс. После чего попытаться ему вместо HwndSource подсунуть свою реализацию и таким образом запустить цельнотянутый WPF поверх инфраструктуры авалонии. Да, там будет часть вещей просто не работать, но портирование облегчит уж точно.
У нас сейчас есть план дождаться полной выкладки WPF в опенсорс
а это разве не полная версия?
«We have published only a small part of the WPF source. We will continue to publish WPF components as part of the .NET Core 3 project. We will publish source and tests at the same time for each component.»
Вот RoadMap: github.com/dotnet/wpf/blob/master/roadmap.md
А лицензия?
поэтому, если вы пишИте приложение для платформы .Net,
Кажется, я немного запоздал с комментарием, но всё же напишу его.
Очень смущает, что конструкторы в примерах все internal, а Init-методы — public. То есть создание компонента ограничено, но вот инициализировать готовый может кто угодно.
Конструкторы должны быть public, а методы инициализации — protected (protected internal в недрах самого фреймворка).
SpaceVIL — кроссплатфоремнный GUI фреймворк для разработки на .Net Core, .Net Standard и JVM