Как стать автором
Обновить

SpaceVIL — кроссплатфоремнный GUI фреймворк для разработки на .Net Core, .Net Standard и JVM

Время на прочтение 17 мин
Количество просмотров 27K
Всего голосов 35: ↑34 и ↓1 +33
Комментарии 29

Комментарии 29

А можно узнать цель фреймворка.

т.е. если это компания стартап, которой нужно какой-то пульт от своего саса завернуть под десктоп — они юзают электон.

Если уже надо сделать качественно и без дропов — пишут натив.

Чем этот фреймворк отличается выгоднее от электрона, который позволяет из говна и палок собрать работающее решение, и есть ли в нем надежность натива?

По всей видимости оно вполне себе пригодно как встраиваемое решение для игр, благо рендерится самостоятельно средствами OpenGL.

Основная идея — это предоставить простую в использовании и кроссплатформенную альтернативу при проектировании десктопного UI для JVM и .Net Core.
Ну и я понимаю, что просто так и сразу люди не перейдут на эту технологию. Изначально, фреймвок в некоторой степени рассматривался в применении программистами бэк-энда, которые никак не связаны с фронтом, но в силу некоторых обстоятельств (рабочих, либо просто по желаю) захотели некоторый бэк-энд обернуть в GUI, но без потерь во времени и преодоления порога вхождения при изучении любой современной GUI системы. Другими словами целью было создать систему GUI с максимально низким порогом вхождения.

1) Что с разметкой? Всё кодом? Если есть нормальная разметка, то есть ли к ней визуальный дизайнер/превьювер?
2) Как обстоят дела с data binding и прочими MVVM?
3) Есть ли виртуализация списков?


Если ничего этого нет, то можно с тем же успехом взять GTK#/QML.NET.


Далее, у вас указано, что оно базируется на glfw. Как обстоят дела с непрямоугольными векторными элементами интерфейса типа кривых безье? Все векторные иконки сейчас на них.

1) Пока все кодом, дизайнера пока нет, но он в планах
2) Система, похожая на data binding (WPF) сейчас в разработке, проектируется наиудобнейший подход, но пока до релиза далеко
3) То же самое как во втором пункте

По поводу произвольных фигур — можно любую фигуру создать и использовать в интерфейсе, но нужно ее предоставить в триангулированном виде. Класс для работы с кривыми безье тоже есть, но в силу его незаконченности пока не доступен в текущем билде.

Будете заниматься разметкой — гляньте на https://github.com/kekekeks/XamlIl Мы его сейчас вкручиваем для компиляции XAML-а билд-таской в MSIL. В итоге после сборки в отладчике это выглядит примерно вот так:


Скрытый текст

Ваши графы объектов, где только контролы и подписки на их события, оно по идее должно уметь грузить чуть ли не из коробки.

Ок. Спасибо, стоит попробовать.
но нужно ее предоставить в триангулированном виде

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

Mac OS X же вообще запрещает создавать мультиоконные приложения, ибо требует, чтобы GUI был запущен только в главном потоке приложения.

Я не знаю, что именно у вас там за ограничения, но мы вообще успешно рисуем в несколько окон с одного NSOpenGLContext. Есть подозрение, что вы пытаетесь использовать OpenGL на виртуалке, в таком случае случаются знатные спецэффекты.

Вы окна создаете с использованием glfw?

Нет, с использованием NSWindow, как предписывает эпловская документация.

Понятно. Mac OS X не позволяет при использовании glfw создавать за раз больше одного окна. Естественно, я сейчас тоже все чаще думаю о том, чтобы написать свой мини-аналог glfw, чтобы использовать необходимый потенциал разных ОС, но в данный момент я пока не могу отказаться от glfw.

А IDE какое? Своё или интегрируется в студию? А когда появится визуальный редактор форм — то где он будет?

IDE любое на ваш выбор, использование SpaceVIL не отличается от использования любой другой библиотеки, поэтому неограничен в выборе IDE.
По поводу редактора. Первая версия планируется в виде отдельного приложения (наподобие JavaFX Scene Builder), которое будет синхронизироваться с открытым проектом в любой выбранной IDE.
Интересно. Код проекта закрыт?
Ну, код на Java и .Net успешно декомпилируется.
Здравствуйте.
Я так понял мне, как интегратору 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 поверх инфраструктуры авалонии. Да, там будет часть вещей просто не работать, но портирование облегчит уж точно.

Круть! Сделайте анонс на хабре обязательно, я так понимаю это тоже уже ближе к 2020 будет, т.к. MS там что-то совсем не шевелятся с выкладкой на GitHub.
У нас сейчас есть план дождаться полной выкладки 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

А лицензия?

Лицензия свободная. Используйте в любых целях, в том числе и коммерческих, но, как обычно, без гарантий «As Is».
Крайне интересное начало, но под конец както стало не очень интересно. Нету ссылок ни на исходные коды, да и никаких Nuget-ов не завезли: надо както руками добавлть референсы, да еще и бинарники в репозиторий тащить (как самой библиотеки, так и зависимостей). Печаль.
В nuget со временем скорее всего появится
без nuget пакета вы предлагаете каждому подключать какуюто непонятную dll, таскать ее по репозиториям, да еще делать это не имея ее исходников и механизмов контроля вредоносности хотябы минимальной? Интересный маркетинговый ход по закапыванию своего проекта, даже не родившегося толком.
ПишЕте
поэтому, если вы пишИте приложение для платформы .Net,

Кажется, я немного запоздал с комментарием, но всё же напишу его.


Очень смущает, что конструкторы в примерах все internal, а Init-методы — public. То есть создание компонента ограничено, но вот инициализировать готовый может кто угодно.


Конструкторы должны быть public, а методы инициализации — protected (protected internal в недрах самого фреймворка).

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории