Комментарии 166
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
WPF на самом деле простой, стоит только перешагнуть через понимание MVVM и окажется, что даже проще разрабатывать, чем на винформах
WPF прекрасно развивается в Avalonia UI :)
На WPF можно разрабатывать как на WinForms, без MVVM.
MVVM не главная боль. Перегруженные привязки, можно уж и попроще было, Avalinia ведь смогла. Опять же без некоторых доп зависимостей всё же пользоваться неудобно, очень. К примеру стандартными средствами крайне больно добавлять свою функциональность к сторонним компонентам.
Перегруженные привязки, можно уж и попроще было, Avalinia ведь смогла.
В Avalonia делали всё же с оглядкой на существующее как никак и не было задачи сделать 100% поддержки и поведения как у WPF. И это же майки и корпоративный сегмент, нельзя просто взять и выкинуть то что уже сделано.
К примеру стандартными средствами крайне больно добавлять свою функциональность к сторонним компонентам.
А можно пример посмотреть в чем именно боль? В идеале бы конечно еще и в сравнении с Avalonia (пока только начал на нее поглядывать), но и без этого интересно.
Одно слово: BooleanToVisibilityConverter.
ну а что тут странного? boolean — 2 значения, visibility — 3. Что во что конвертировать?
Это неприятный аспект, но при грамотном подходе не является проблемой.
Например, в нашем проекте (Github) в 97 случаев используется стандартный BoolToVisibilityConverter (который конвертирует false в Visibility.Collapsed) и в 10 случаях дополнительный BoolToHiddenVisibilityConverter (конвертирует false в Visibility.Hidden).
Например, в нашем проекте (Github) в 97 случаев используется стандартный BoolToVisibilityConverter (который конвертирует false в Visibility.Collapsed) и в 10 случаях дополнительный BoolToHiddenVisibilityConverter (конвертирует false в Visibility.Hidden).
Насколько я знаю — x:Bind из UWP умеет нативно превращать bool в Visibility
К сожалению — пока ещё нет. Всё ещё нужно писать конвертор. И то же самое можно сказать и про валидацию. Но в официальном релизе WunUI 3 валидация уже должна быть.
UWP — умеет, если minSDK 14393 social.technet.microsoft.com/wiki/contents/articles/34846.uwp-compiled-binding-windows-10-anniversary-update.aspx
Прост он ровно до тех пор, пока не пытаешься решить проблемы связанные с анимацией, триггерами и/или стилями…
А что со стилями и триггерами не так? Не сложнее css и подобного. Всё примерно как везде в среднем. Очень удобно кастомизировать всё и вся.
С анимациями да, посложнее, но Blend неплохо помогает первое время.
С анимациями да, посложнее, но Blend неплохо помогает первое время.
Это Вы сейчас про то, что CSS становится всё более и более нетривиальным?
Хех) всё же я не про это. Мне не казалось что стили триггеры и тд в WPF прям уж сложные. Проблемы обычно начинаются, когда пытаешься всю логику в них запихнуть. В таких случаях лучше расширить имеющися элемент(или унаследоваться от имеющегося или создать свой кастомый контрол) и уже в code behind описывать необходимую логику/данные для анимации/т.д. в зависимости от необходимости, а не раздувать xaml.
Сам долгое время пытался всё запихнуть в xaml.
Сам долгое время пытался всё запихнуть в xaml.
А что делать тем, кто пишет на си++ без CLI?
Игнорировать весь этот зоопарк технологий и использовать Qt / WinAPI напрямую, как и раньше.
К сожалению Qt меняется в худшую сторону, уже одно то, что нет оффлайн инсталляторов бесплатных по сути дискредитирует его как OpenSource. Интерфейс выглядит устаревшим и мало развивается. Мне кажется? с таким подходом Qt повторит судьбу Дельфи. Мое мнение может быть неверным, я использую в основном как быстрый интерфейс к железу, но в целом, Qt сильно проигрывает последним VS.
Страдать…
(я сам плюсовик, так что да)
(я сам плюсовик, так что да)
Как вариант, можно подождать релиз и попробовать использовать. В Windows UI Library Roadmap, есть четкое указание на чем написан WinUI: WinUI can be used with .NET, but doesn't depend on .NET: WinUI is 100% C++ and can be used in unmanaged Windows apps, for example using standard C++17 via C++/WinRT.
Тоже использовать WinUI. Он не привязан к .Net вообще
Так то винформы и для C++ есть, проблема в том, что реализовано оно через .NET костыль, и в целом криво.
Сделай они нормальные винформы для плюсов — могли бы составить достойную конкуренцию QT. Почему не сделали — не очень понятно, видимо считали что будущее только за .NET.
Сделай они нормальные винформы для плюсов — могли бы составить достойную конкуренцию QT. Почему не сделали — не очень понятно, видимо считали что будущее только за .NET.
MFC?
Как результат — у нас есть мощная платформа, с унифицированным программным и визуальным интерфейсом. Наш стандартный калькулятор уже построен как UWP приложение
Вот по моему я только калькулятором и пользуюсь из всего нативного, ну explorer и настройки. Остальное либо веб, либо electron либо java. Может это моя специфика такая. Имхо рынок нативного windows софта должен уменьшаться. Вряд ли кто то нынче захочет себя ограничивать себя одной какой то платформой хоть и такой распространенной. Тот же веб это и мультиплатформенное и база пользователей у себя. Только если какой то софт под заказ. Или реально рынок такой большой?
Поддерживаю, браузеры более защищены и мы даём сайтам те права, которые мы считаем нужным, сразу исключается скрытая запись с микрофона или веб камеры
Открою секрет, но винда тоже позволяет запрещать доступ к камере, микрофону и пр.*
*Только для UWP приложений.
*Только для UWP приложений.
Вот только с браузером Вы не сделаете офлайн приложение, которое сможет синхронизироваться с облаком, когда появится доступ в интернет. Это, конечно, ниша энтерпрайза, но всё же она достаточно большая
Если только сам браузер не слушает )
Как мне в браузере сделать работу с локальными файлами? Нет, не с какой-то там песочницей, расположенной непойми где, а прямо с файлами, в произвольной указанной пользователем директории? Заворачивать целый браузер в электро не предлагать.
Как мне в браузере сделать работу с локальными файлами? Нет, не с какой-то там песочницей, расположенной непойми где, а прямо с файлами, в произвольной указанной пользователем директории?
expressflow.com/blog/posts/file-system-access-api-for-the-web-chrome
Вначале они отменили сильверлайт. Потом — предали винфон. WPF остается популярнейшей платформой, но уже считается устаревшей. А стоит ли участвовать в этих крысиных бегах?
а есть достойная альтернатива для .net? и, за пределами тоже не все так сладко.
Полагаю, что Microsoft не получает удовольствия от поддержки огромного количества схожих технологий. И сейчас идёт период «объединения». Примером тому служат платформы .NET Framework и .NET Core, которые слились в .NET 5.
Так же, совсем недавно компания прекратила поддержку .NET Core 2, что ещё больше демонстрирует уверенные действия в унификации платформы.
Так же, совсем недавно компания прекратила поддержку .NET Core 2, что ещё больше демонстрирует уверенные действия в унификации платформы.
Надеюсь, им удастся сделать всеплатформенный WPF, и мы сможем забыть 100-мегабайтные калькуляторы на электроне.
Зачем микрософту делать "всеплатформенный wpf", когда уже есть Avalonia?
А если забыть о .net, то уже есть Qt
Ну да. Или пусть купят Qt и мы все полюбим QML.
И получим не менее тормознутые калькуляторы на WinUI? Не знаю, на чем нынче написан интерфейс винды, но у меня на не самом слабом ноутбуке открытие календаря, электропитания итп по клику на таскбаре занимает… занимает какое-то время, которое я успеваю заметить. Пусть быстро, но все равно слишком медленно для такой простой задачи на Core i7.
там поди в видеокарточке проблемы.
А какие нынче минимальные требования по видеокарте для запуска калькулятора?
проблема в загрузке зависимостей и интерпретации Ксамла
так xaml не интерпретируется, он компилируется.
Хорошее уточнение, но неполное.
Компилируется он в BAML, который все равно требует интерпретации в рантайме, что небыстро.
Компилируется он в BAML, который все равно требует интерпретации в рантайме, что небыстро.
и снова неполное замечание, в UWP (WinRT) он компилируется в XBF, который действительно бинарный.
Ну а пуск, центр действий и прочие всплывашки — это UWP
Ну а пуск, центр действий и прочие всплывашки — это UWP
А не подскажете ли способ остановить UWP?
что значит «остановить»?
Ку вот, к примеру, не нужна мне выезжающая справа боковая панель в Windows 10, да и нечёткость переключения фокуса ввода бесит (подозреваю, без UWP здесь не обошлось, ему ведь как-то нужно вклиниваться).
Есть ли единый процесс/служба, отвечающие за отрисовку всего этого функционального богатства?
Есть ли единый процесс/служба, отвечающие за отрисовку всего этого функционального богатства?
Ну тогда вам надо откатиться на 7ку. Потому что UWP это по сути приложения с определённым жизненным циклом поверх WinRT. И в будущем всё больше компонентов системы будет работать именно на этом новом API.
А что вы подразумеваете под нечёткостью переключения фокуса?
А что вы подразумеваете под нечёткостью переключения фокуса?
В XP/7 по Alt-Tab практически всегда попадаю в нужное окно, клавиатурный ввод и мышка попадают чётко куда направлены. В 8/10 такого ощущения нет, не говоря уже о невозможности добраться до нужного контрола без мышки Tab'ом — похоже в UWP поддержка порядка контролов — моветон.
хм, у меня никогда не было проблемы с alt-tab.
Более того буквально вчера я пользовался девайсом, где есть только клавиатура. Запускал обновление, подключался к wi-fi, открывал стор и центр действий, взаимодействовал с уведомлениями. Есть некоторые моменты, которые можно сделать лучше, но не так, что табом и стрелками не добраться туда, куда мне нужно.
Более того буквально вчера я пользовался девайсом, где есть только клавиатура. Запускал обновление, подключался к wi-fi, открывал стор и центр действий, взаимодействовал с уведомлениями. Есть некоторые моменты, которые можно сделать лучше, но не так, что табом и стрелками не добраться туда, куда мне нужно.
На этом компьютере особенно специфического ПО нет.
Ну скажем, переключаюсь между офисом и браузером. Туда — Alt-Tab, обратно часто приходится нажимать Alt-Tab дважды, при первом нажатии фокус часто не меняется.
Бывает, переключился но Alt-Tab, фроде бы фокус клавиатурный переключился, начинаю набирать текст — он не попадает в контрол, приходится либо мышкой тыкнуть в контрол, либо в заголовок окна (тоже часто квест в связи с выставленными системой цветами, когда заголовок того же цвета, что и окно).
В общем, вроде бы всё по мелочи, но складывается впечатление какого-то бесплатного продукта с командой в полтора разработчика.
А магией навигации через UWP Tab'ом овладеть не удаётся прямо никак.
Ну скажем, переключаюсь между офисом и браузером. Туда — Alt-Tab, обратно часто приходится нажимать Alt-Tab дважды, при первом нажатии фокус часто не меняется.
Бывает, переключился но Alt-Tab, фроде бы фокус клавиатурный переключился, начинаю набирать текст — он не попадает в контрол, приходится либо мышкой тыкнуть в контрол, либо в заголовок окна (тоже часто квест в связи с выставленными системой цветами, когда заголовок того же цвета, что и окно).
В общем, вроде бы всё по мелочи, но складывается впечатление какого-то бесплатного продукта с командой в полтора разработчика.
А магией навигации через UWP Tab'ом овладеть не удаётся прямо никак.
Ну скажем, переключаюсь между офисом и браузером. Туда — Alt-Tab, обратно часто приходится нажимать Alt-Tab дважды, при первом нажатии фокус часто не меняется.Если браузер — это новый эдж, то сейчас по-умолчанию, в Alt+Tab попадают 5 последних переключенных вкладок. Т.е. из офиса переходите в Edge, переключаете вкладку и alt-tab перенесет вас на предыдущую вкладку.
Фича неоднозначная, но отключается в настройках многозадачности
Edge пропустил, и старый и новый. FF, реже хром. Группировку окон на панели задач отключаю — мне так удобнее.
Поинтересовался так как действительно с удовольствием бы выключил все «неоднозначные фичи» типа возникновения непрошенных окон при наведении курсора на всё новые магические точки и прочее, пытался как то найти самостоятельно найти, неосилил.
Поинтересовался так как действительно с удовольствием бы выключил все «неоднозначные фичи» типа возникновения непрошенных окон при наведении курсора на всё новые магические точки и прочее, пытался как то найти самостоятельно найти, неосилил.
Поинтересовался так как действительно с удовольствием бы выключил все неоднозначные фичи типа возникновения непрошенных окон при наведении курсора и прочее, пытался как то найти самостоятельно найти, неосилил.Это вы про Aero Peak на таскбаре? так он с семерки там. Поди где-нибудь в реестре флаг есть. По названию можно нагугить.
ну а насчет alt-tab из FF, есть подозрение, что проблема в FF.
Может и так, спасибо за проявленное участие.
Подумал — а как проблема с Alt-Tab может быть связана с приложениями вообще — это же функциональность GUI.
ну, некоторые приложения пытаются делать разные хаки с системой. Просто то, что вы описываете, я никогда не ловил. Попробуйте с другими приложениями воспроизводится или нет?
Не всегда ведь понятно, с каким приложением возможна проблема. Да, браузер запущен практически постоянно. Но ведь и на семёрке FF пока актуализируется, если бы была его вина — чувствовалось бы и там.
Ну и самые глубокие хаки с Windows производит офис, и ничего обычно, хотя команды разработчиков разные.
ОС не должна быть в идеале подвержена хакам со стороны ПО. Но с тех пор, как стало нормой держать рабочий экземпляр браузера в профиле пользователя, удивляться нельзя ничему.
Ну и самые глубокие хаки с Windows производит офис, и ничего обычно, хотя команды разработчиков разные.
ОС не должна быть в идеале подвержена хакам со стороны ПО. Но с тех пор, как стало нормой держать рабочий экземпляр браузера в профиле пользователя, удивляться нельзя ничему.
А магией навигации через UWP Tab'ом овладеть не удаётся прямо никак.А в чем проблема?
к примеру, открываю пуск. Стрелка вниз навигирует по списку приложений. Таб переключает между боковым меню, списком и тайлами. Стрелки навигируют внутри этих блоков. Enter или пробел — аналог клика (на самом деле они немного разные). Кнопка Меню, вызывает контекстное меню.
Пуск не предпочитаю, нужные приложения запускаю хоткеями, большую часть функциональности проводника заменяю Far manager'ом, в принципе недалёк от мысли оставить его Shell'ом — лень мне и неинтересно исследовать, куда перепрятаны привычные настройки после очередного обновления системы.
Проблема в том что в большинстве новых окон Tab не добирается в принципе до некоторых пунктов, да и долго клацать.
Проблема в том что в большинстве новых окон Tab не добирается в принципе до некоторых пунктов, да и долго клацать.
Проблема в том что в большинстве новых окон Tab не добирается в принципе до некоторых пунктов, да и долго клацать.Т.е. вы не пользуетесь ни одним UWP приложением, но жалуетесь, что из-за UWP у вас Tab не работает?
Почти не пользуюсь. Жалуюсь на то, что привычная функциональность скрывается за (не заменяется) UWP приложениями, а они мешают обычному использованию привычных инструментов.
Впрочем, возможно не всегда верно идентифицирую какое-либо окно как UWP.
Впрочем, возможно не всегда верно идентифицирую какое-либо окно как UWP.
похоже в UWP поддержка порядка контролов — моветон
Тут не в UWP проблема, а в программистах. Так-то порядок контролов при переключении через Tab задаётся похожим образом что в WinForms, что в WPF, что в UWP, что в HTML. Вопрос лишь в том, следит ли за этим программист, или забил.
ЕМНИП IDE раньше за этим следила сама, т.е. можно было поправить при необходимости, но какое-то значение по умолчанию Z-control получал всегда.
То есть забили разработчики IDE?
То есть забили разработчики IDE?
ЕМНИП IDE раньше за этим следила сама, т.е. можно было поправить при необходимости, но какое-то значение по умолчанию Z-control получал всегда.В любом случае, UWP никак не влияет на переключение фокуса в вашей IDE (она же не на UWP написана?).
То есть забили разработчики IDE?
А вообще, сейчас открыл студию и вспомнил, что кроме Tab есть ещё и ctrl+tab, и как я из-за этого не смог в Paint.net на тулбар переключиться.
Именно что "какое-то". Насколько я помню, что в Delphi, что в Visual Studio tab order по умолчанию формировался на основе порядка добавления контролов (если я помню неправильно — поправьте кто знает). В итоге в формах, сделанных "в один присест" он был адекватным, но по мере доработок всегда расходился со здравым смыслом.
Тут как раз в XAML получился шаг вперёд, поскольку теперь архитектурно невозможно завязаться на порядок добавления контролов на форму, и фреймворку приходится определять порядок на основе структуры формы. Возможно, не всегда это получается, но именно по части умолчаний стало лучше чем было.
«Какое-то» достижимое кмк всё же лучше чем никакое вовсе. После предыдушего обновления Windows у меня отказали все usb порты. Хорошо, что нашлась именно ps/2 мышка, а не клавиатура — с помощью мышки и экранной клавиатуры смог войти в систему и запустить полное обновление с сохранением настроек. Если бы была клавиатура, но без мышки — вряд ли бы помогло.
Кстати, эмулятор клавиатуры с помощью мышки в Windows есть, а эмулятора мышки с помощью клавиатуры нет со времён W98.
Прогрессивность архитектуры кмк не должна ломать UX, пока это не полноценный нейроинтерфейс конечно.
Кстати, эмулятор клавиатуры с помощью мышки в Windows есть, а эмулятора мышки с помощью клавиатуры нет со времён W98.
Прогрессивность архитектуры кмк не должна ломать UX, пока это не полноценный нейроинтерфейс конечно.
Хорошо, порыл поглубже тему. Похоже, про интерпретацию в рантайме я был неправ.
Только загрузка формы (и генерация дерева UI-объектов) может быть медленной, а биндинги — обычный IL код, привязываются через рефлексию на этапе загрузки XBF/BAML/XAML.
И похоже, что XBF имеет разные версии для Win8.1 и позднее. Нашел парсер на гитхабе.
Только загрузка формы (и генерация дерева UI-объектов) может быть медленной, а биндинги — обычный IL код, привязываются через рефлексию на этапе загрузки XBF/BAML/XAML.
И похоже, что XBF имеет разные версии для Win8.1 и позднее. Нашел парсер на гитхабе.
Да, есть как минимум две версии XBF
а биндинги — обычный IL код, привязываются через рефлексию на этапе загрузки XBF/BAML/XAML.И да, и нет. В UWP (и WinUI) есть компилируемые x:Bind фактически биндинги кодогенирируются как часть класса.
Да нет, всё вы правы были. Вопрос-то был в медленном запуске приложения, а эта самая "только загрузка формы (и генерация дерева UI-объектов)" обычно как раз при запуске и происходит.
генерация дерева происходит везде, не только в UWP/WPF. И она не объясняет тормозов календаря, про которые говорил Alex_ME
И плохо объясняет тормоза UWP приложений на старте, потому что там какая-то магия ещё до старта творится, и куча времени проходит до момента создания этого самого визуального дерева.
И плохо объясняет тормоза UWP приложений на старте, потому что там какая-то магия ещё до старта творится, и куча времени проходит до момента создания этого самого визуального дерева.
А система на SSD стоит?
Да, на SSD. Но вообще, получается, это какие должны быть требования, чтобы в 2021 году у меня КАЛЕНДАРЬ не тормозил? Не то, чтобы меня раздражала задержка в несколько сот миллисекунд при открытии календаря, но в том же Gnome аналогичный виджет не подвисает.
Меня раздражает сам факт
А ведь есть и более легковесные окружения… Если системе недостаточно мобильного i7-7xxx, обязателен SSD и прочее и прочее для отрисовки виджета календаря, быть может, мы просто не туда свернули? Может, не нужна анимация подсвеченных соседних дат, может не нужны эти acrillic цвета и хитрые анимации? Может, графические фреймворки должны быть сделаны как-то более оптимально?
кстати, пробовали отключить анимации? может дело в них?
Так же, совсем недавно компания прекратила поддержку .NET Core 2
Еще не прекратила
Для .NET Core 2.1 заявлена поддержка до 21.08.21.
PS Вас видимо сбило с толку, что прекращена поддержка более позднего выпуска 2.2. Однако с .NET Core 2 такая вот загогулина вышла.
НЛО прилетело и опубликовало эту надпись здесь
На самом деле, после того, как WinForms стал оупенсурсным, комьюнити проявило достаточно большой интерес к нему. Поэтому, в .NET 5 для форм приготовили несколько фишек. Среди них улучшенные компоненты и безумная оптимизация:
Больше информации можно прочитать в этой статье: What’s new in Windows Forms runtime in .NET 5.0
Поэтому, уже не раз сталкиваюсь с тем, что формы всерьёз начали расценивать как возможную платформу для небольшого нового проекта.
Больше информации можно прочитать в этой статье: What’s new in Windows Forms runtime in .NET 5.0
Поэтому, уже не раз сталкиваюсь с тем, что формы всерьёз начали расценивать как возможную платформу для небольшого нового проекта.
M$ уже сами набегались так что запутались куда идти, в винде целый зоопарк, HiPDI нормально поддерживает только часть из них.
Про MAUI я слышал, а вот про Uno впервые. Хорошая вещь? Стоит ли изучать?
Для начала, нужно понимать, что Uno Platform — просто способ запускать UWP и WinUI приложения на разных платформах. С Uno я работаю уже достаточно долгое время, и меня не перестаёт радовать то, как быстро развивается эта технология. Моя задача стояла в развитии кроссплатформенного направления компании. И в первую очередь речь зашла о C#. После долгих дискуссий выбор стоял между GTK, AvaloniaUI и Uno Platform. Подкупало то, что помимо обещанных Windows, Mac и Linux, была возможность собирать приложения под мобильные платформы и даже Web Assembly. Вот это я понимаю — кроссплатформенность. И мы решили рискнуть, выбрав Uno.
В целом — технология работает. Но не без подводных камней. Начиная от того, что некоторые функции не реализованны, и заканчивая отсутствием целых компонентов. Например, для работы с глобальными событиями клавиатуры, у UWP есть класс KeyboardAccelerator. Но у UNO его нет… И таким образом, нигде, кроме как на Windows, у тебя это работать не будет.
Тем не менее, от Uno Platform мы не отказались, и сделать работающий продукт вполне возможно.
Часто бывает такое, что тебе необходима какая-то функция/метод, который ещё не перенесён в Uno. Я создаю Issue у них на гитхабе, прихожу на следующий день, обновляю nuget пакет, и она уже реализованна. Так же, у тебя всегда есть возможно контрибьютить проект лично.
Для понимания всей мощи технологии, команда разработчиков сделала несколько оупенсурсных приложений с использованием своей технологии. Среди них и калькулятор Windows(да, он теперь кроссплатформенный).
Так же, в команде разработчиков Uno есть несколько Microsoft MVP. Вся команда очень активно сотрудничают с командами Microsoft для улучшения своего детища. Например, с командой Xamarin. Так же, у команды есть свой Discord сервер, где каждый день проходят дискуссии и обсуждения. Присоединится: https://discord.gg/eBHZSKG
И в окончании хочу сказать, что Microsoft очень позитивно относится к Uno Platform и всячески пытается им помогать. Для большего понимания, что из себя представляет Uno, рекомендую посмотреть недавний стрим на официальном канале Microsoft Visual Studio на youtube о возможностях Uno Platform с одним из главных разработчиков:
В целом — технология работает. Но не без подводных камней. Начиная от того, что некоторые функции не реализованны, и заканчивая отсутствием целых компонентов. Например, для работы с глобальными событиями клавиатуры, у UWP есть класс KeyboardAccelerator. Но у UNO его нет… И таким образом, нигде, кроме как на Windows, у тебя это работать не будет.
Тем не менее, от Uno Platform мы не отказались, и сделать работающий продукт вполне возможно.
Часто бывает такое, что тебе необходима какая-то функция/метод, который ещё не перенесён в Uno. Я создаю Issue у них на гитхабе, прихожу на следующий день, обновляю nuget пакет, и она уже реализованна. Так же, у тебя всегда есть возможно контрибьютить проект лично.
Для понимания всей мощи технологии, команда разработчиков сделала несколько оупенсурсных приложений с использованием своей технологии. Среди них и калькулятор Windows(да, он теперь кроссплатформенный).
Так же, в команде разработчиков Uno есть несколько Microsoft MVP. Вся команда очень активно сотрудничают с командами Microsoft для улучшения своего детища. Например, с командой Xamarin. Так же, у команды есть свой Discord сервер, где каждый день проходят дискуссии и обсуждения. Присоединится: https://discord.gg/eBHZSKG
И в окончании хочу сказать, что Microsoft очень позитивно относится к Uno Platform и всячески пытается им помогать. Для большего понимания, что из себя представляет Uno, рекомендую посмотреть недавний стрим на официальном канале Microsoft Visual Studio на youtube о возможностях Uno Platform с одним из главных разработчиков:
Только не пойму, приложения WinUI 3 будут устанавливаться через маркетплейс или как нормальные приложения? От UWP я отказался именно по этой причине. Пробовал WinUI 3 в Visual Studio. Там предлагает два варианта: базовую библиотеку либо приложение под Маркетплейс (что мне не нравится).
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за комментарий. На данный момент приложения на WinUI поддерживают только MSIX упаковку, которая нужна по большей части для Microsoft Store.
Но, в github репозитории Project Reunion можно найти много интересного. В том числе, и информацию по упаковке приложения:
И там присутствует очень интересная таблица с планами на развитие:
Из неё видно, что приложения на WinUI + .NET будут поддерживать классическую упаковку. Но этого стоит ждать ближе релизу.
Но, в github репозитории Project Reunion можно найти много интересного. В том числе, и информацию по упаковке приложения:
И там присутствует очень интересная таблица с планами на развитие:
Из неё видно, что приложения на WinUI + .NET будут поддерживать классическую упаковку. Но этого стоит ждать ближе релизу.
Скорее бы.
А то недавно был очень неприятно удивлен, когда выяснилось, что для интегрированной графики Intel, панель управления теперь (пока?) можно скачать ТОЛЬКО через MS Store.
Панели управления Nvidia, это кстати, тоже касается, но там хотя бы это ещё можно обойти, поставив классический Win32.
P.S.
Когда читаю подобные статьи про различные упаковки от Microsoft, всегда вспоминаю эту статью):
habr.com/ru/company/itsumma/blog/450846
Пасиб за разбор.
А то недавно был очень неприятно удивлен, когда выяснилось, что для интегрированной графики Intel, панель управления теперь (пока?) можно скачать ТОЛЬКО через MS Store.
Панели управления Nvidia, это кстати, тоже касается, но там хотя бы это ещё можно обойти, поставив классический Win32.
P.S.
Когда читаю подобные статьи про различные упаковки от Microsoft, всегда вспоминаю эту статью):
habr.com/ru/company/itsumma/blog/450846
Пасиб за разбор.
Меня бесит, когда для показа небольшого приложения с настройками, раскиданными по табам, свежие версии ScrewDrivers (программа для печати через RDP-соединение) требуют установки определённых версий .NET. Не говоря уже о Runtime-пакетах VC++ на сервере и клиенте. Имеем ввиду, что для RDP-подключений специально закупаются недорогие ноуты, чтобы крутить программы на сервере. А ведь вместо этого можно было написать компактные приложения на Delphi, которые не требовали бы установки ни .NET, ни Visual C++ Redistributable Packages. И при этом работали бы на любых Windows от XP до 10, 32-bit и 64-bit.
Спасибо за комментарий. На данный момент приложения на WinUI поддерживают только MSIX упаковку, которая нужна по большей части для Microsoft Store.Нет она нужна для винды. Это новый формат распространения приложений, в котором МС постаралась пофиксить баги MSI. К стору это распространение не особо привязано.
По заявлениям самих Microsoft, на WinUI 3 и его последующие версии, у компании огромные планы.
Ну вот когда собственный Skype с $%#@ного электрона на эту чудо-технологию перепишут, вот тогда мы и посмотрим, что за WinUI 3. Как говорится, eat your own dog food.
Более того, они хотят Outlook for MacOS переписать на Electron, шизофрения в действии)
https://9to5mac.com/2021/01/05/microsoft-outlook-mac-web-app/
UWP активно объединяет системные функции и компоненты под единым программным интерфейсом, который теперь может работать на всех устройствах с Windows 10 без изменений в коде! Но, это касается не только программных функций, но и визуальных компонентов. Так и появляется на свет WinUI 2 — единый визуальный интерфейс для всех приложений на Windows.
Мне кажется, любое приложение будет работать на любом устройстве с Windows 10 без перекомпиляции кода, если оно совместимо с этой ОС и не использует сторонних компонентов. Хоть Winforms, хоть WPF, хоть консоль. Или автор что-то другое хотел сказать?
Я так понимаю, речь была о win10 ARM, Hololens, и XBOX
Да, совершенно верно.
Допустим есть у нас такая программа:
А стоят Hololens и XBOX еще одного очередного фреймворка?
UWP выглядел логично пока были Windows Phone/Mobile. Зачем он нужен после смерти последнего? Создается ощущение, что выпустили очередной UWP просто чтобы добавить разработчикам головной боли, им же заняться больше нечем, кроме как изучать очередной мертворожденный UI.
using System.Windows.Forms;
class MyForm : Form
{
static void Main()
{
Application.Run(new MyForm());
}
}А стоят Hololens и XBOX еще одного очередного фреймворка?
UWP выглядел логично пока были Windows Phone/Mobile. Зачем он нужен после смерти последнего? Создается ощущение, что выпустили очередной UWP просто чтобы добавить разработчикам головной боли, им же заняться больше нечем, кроме как изучать очередной мертворожденный UI.
Будучи скомпилирована как AnyCPU она не запустится на Win10 ARM?на Windows 10 ARM запустится. На Windows 10X — нет
Это не новый UI, а лишь продолжение WinUI 2, который теперь может работать как .NET приложение, а не UWP.
Который может работать как Win32 приложение. А не быть ограниченным жизненным циклом UWP. .Net там сбоку стоит
Зачем?
Windows Forms может работать как .NET приложение.
WPF может работать как .NET приложение.
Им надо сообразить на троих? :)
Windows Forms может работать как .NET приложение.
WPF может работать как .NET приложение.
Им надо сообразить на троих? :)
Формы на данный момент уже являются устаревшей технологией, которая находится на пике развития и уже не сможет пробить потолок.
WPF ещё хорош, но у WinUI куда больше функций и возможностей.
С точки зрения дизайна — WinUI может дать нам Reval эффекты, Acrylic цвета, много возможностей для работы с моушн эффектами и даже поддерживает Lottie анимации.
С точки зрения функциональности — у WinUI куда больше возможностей. Банально, вчера я тестировал компонент, который позволяет трэкать глаза пользователя, работая с Tobii Eye Tracker.
Что б посмотреть все возможности WinUI, рекомендую потыкать Xaml Controls Gallery и
Windows Community Toolkit Sample App.
WPF ещё хорош, но у WinUI куда больше функций и возможностей.
С точки зрения дизайна — WinUI может дать нам Reval эффекты, Acrylic цвета, много возможностей для работы с моушн эффектами и даже поддерживает Lottie анимации.
С точки зрения функциональности — у WinUI куда больше возможностей. Банально, вчера я тестировал компонент, который позволяет трэкать глаза пользователя, работая с Tobii Eye Tracker.
Что б посмотреть все возможности WinUI, рекомендую потыкать Xaml Controls Gallery и
Windows Community Toolkit Sample App.
И на чём же в итоге Microsoft пишет Visual Studio Code?
«Свободная память — зря купленная память, а простаивающие ядра процессора — зря купленные ядра», — назидательно произнёс индус, переписывая очередное приложение на Electron.
Visual Studio Code MS начало писать на том, что было доступно тогда. Тогда кажется, даже Xamarin.Forms не был поддержан на десктопах, особенно на линуксе. Плюс она же построена вокруг редактора monaco. Так что надо выбирать инструмент по целям. Странно было бы, если б мс VSCode на чем-то другом писали
Развели бардак. В итоге стабильные Формсы живее всех остальных.
Перетянуть разработчиков насильно на новье сложнее, чем обычных пользователей. Да и доля Вин7, которую отказались поддерживать в новых фреймворках, все еще велика (даже сегодня порядка 17%). Потому UWP/WinRT дев-ы бортанули.
.NET 4.8 будет поддерживаться до осени 2029г. Еще есть время посмотреть, кто вымрет.
Конечно, мобильный рынок устр-в живет по своим правилам, там совсем пока непонятно, куда грести (
Перетянуть разработчиков насильно на новье сложнее, чем обычных пользователей. Да и доля Вин7, которую отказались поддерживать в новых фреймворках, все еще велика (даже сегодня порядка 17%). Потому UWP/WinRT дев-ы бортанули.
.NET 4.8 будет поддерживаться до осени 2029г. Еще есть время посмотреть, кто вымрет.
Конечно, мобильный рынок устр-в живет по своим правилам, там совсем пока непонятно, куда грести (
На стартовой картинке кое-чего не хватает, из далекого прошлого.
Если бы разработчикам программ под Windows весь этот срок с 1995 (на самом деле, с 1990, когда началось массовое распространение Windows 3.0) до 2002 пришлось бы плакать, колоться, но продолжать писать программы на голом WinAPI/Win32API «по Петцольду», как они это делали во времена Windows 3.0, то, думаю, Windows бы до наших дней не дожила. Но, даже если брать только продукты для разработчиков самой MS, в 1992 появилась библиотека MFC для C++, потом — Visual Basic и жизнь разработчиков под Windows стала гораздо легче. А если продуктами MS не ограничиваться, то была ещё, к примеру, Borland — сначала с OWL для C++, потом — с Delphi.
Если бы разработчикам программ под Windows весь этот срок с 1995 (на самом деле, с 1990, когда началось массовое распространение Windows 3.0) до 2002 пришлось бы плакать, колоться, но продолжать писать программы на голом WinAPI/Win32API «по Петцольду», как они это делали во времена Windows 3.0, то, думаю, Windows бы до наших дней не дожила. Но, даже если брать только продукты для разработчиков самой MS, в 1992 появилась библиотека MFC для C++, потом — Visual Basic и жизнь разработчиков под Windows стала гораздо легче. А если продуктами MS не ограничиваться, то была ещё, к примеру, Borland — сначала с OWL для C++, потом — с Delphi.
В общем то, почему сразу «были»?
- MFC живет и разви
вапатчится до текущего момента - OWLnext переехала в опенсорс
- VCL же была и остается до сих пор сильнейшим конкурентом Winforms
Очень жду на стабильный релиз, чтобы посмотреть как это всё будет работать в сценарии нативного С++ кода + WinUI 3. Сейчас доля UI в C++ проектах грустная: либо платить Qt (не надо тут сказок о том, что бесплатной лицензии хватит для серьёзного продукта), либо тащить .NET, либо плакать над WinApi/MFC, либо сдаться и взять Электрон. А тут вроде обещают что-то современное и нативное.
(Не реклама, просто делюсь проверенным решением для C++ и XAML, которое может подойти по бесплатной лицензии)
С 2013 года пользуемся и активно помогаем развитию NoesisGUI. Это проприетарная кроссплатформенная библиотека векторного UI, на 99.9% совместимая с API WPF и XAML. Написана на C++, отдельно доступен C# SDK. Ориентировано на AAA геймдев (отсюда потрясающая оптимизация и поддержка C++ в самом лучшем виде), но и приложения писать никто не мешает. Разрешают использовать бесплатно, если годовой оборот компании меньше €100K. Можно поиграться в WebAssembly версию (справа сверху выбор сэмпла).
Т. к. у меня был огромный опыт разработки WPF/SL приложений, эта библиотека здорово помогла в создании очень сложного UI для наших проектов-видеоигр, пользуемся все эти годы. Кстати, интерфейс Baldur's Gate 3 разрабатывают именно с помощью этой библиотеки (после смерти Scaleform выбор технологий для векторного UI в видеоиграх очень невелик).
С 2013 года пользуемся и активно помогаем развитию NoesisGUI. Это проприетарная кроссплатформенная библиотека векторного UI, на 99.9% совместимая с API WPF и XAML. Написана на C++, отдельно доступен C# SDK. Ориентировано на AAA геймдев (отсюда потрясающая оптимизация и поддержка C++ в самом лучшем виде), но и приложения писать никто не мешает. Разрешают использовать бесплатно, если годовой оборот компании меньше €100K. Можно поиграться в WebAssembly версию (справа сверху выбор сэмпла).
Т. к. у меня был огромный опыт разработки WPF/SL приложений, эта библиотека здорово помогла в создании очень сложного UI для наших проектов-видеоигр, пользуемся все эти годы. Кстати, интерфейс Baldur's Gate 3 разрабатывают именно с помощью этой библиотеки (после смерти Scaleform выбор технологий для векторного UI в видеоиграх очень невелик).
И сколько оно стоит для какого-нибудь проекта в вакууме типа «10 разрабов, 1 лям евро в год»?
Я написал им — ответили, что для такого случая стоимость лицензии будет около 1000€ / year / seat. Если кто-то бэкендом только занимается, можно сэкономить. В любом случае, они люди гибкие и договориться о разумной цене очень легко. Ниже xXxVano задавал вопросы по этому продукту и компании в целом — я очень подробно ответил.
На самом деле выглядит очень круто и достаточно быстро работает. Спасибо что написали про неё! Если бы они были opensource то наверное даже был бы смысл попробовать их.
По моим ощущениям любой middleware при разработке игр — это боль. Как и упомянутый вами ScaleForm требует денег (и видимо много — что то в районе $50к-$100к в год?).
По опыту использования других middleware (umbra/enlighten/scaleform/morpheme) — очень часто возникают проблемы с крашами в либах без исходников. А ещё они любят закрываться (только wwise/fmod ещё пока держатся) и после этого приходится самим поддерживать тонну легаси кода.
Этот middleware разработан двумя талантливыми программистами из Испании практически на голом энтузиазме в течение многих лет (мой коллега с ними лично встретился только на GDC 2019, хотя мы одни из их ранних пользователей с 2013 года и наша первая игра была первым серьёзным проектом использующим их библиотеку). И по удачному стечению обстоятельств, у них сейчас просто нет серьёзных конкурентов среди библиотек векторного UI для видеоигр — тем более с устоявшимся workflow (Blend, Visual Studio/Rider для XAML + они активно работают, чтобы добавить новые технологии вроде импорта Lottie (After Effects)).
NoesisGUI использовать в разработке видеоигр на самом деле удобно — особенно если вам уже знаком WPF/XAML/Blend, т. к. по сути дела это оно и есть. Можно почитать множество отзывов из Unity Asset Store. К слову, для последней игры я разработал свой игровой движок и пишу код UI на XAML как обычное WPF Application (код игры в опенсорсе (включая сотни XAML файлов/C#/шейдеры HLSL/графика/звуки/т. д.), можно посмотреть все ~0.5 млн строк кода и увидеть как всё организовано). Код XAML (равно как и сопутствующий ему C# код) автоматически используется as is и поддерживает горячую перезагрузку (в принципе сам движок заточен на горячую перезагрузку всего и вся, ну и на моддинг — фактически сама игра это мод к движку). В итоге процесс разработки и отладки очень быстрый, так что мне даже не приходится использовать XAML Designer.
Но обычно просто делают два параллельных проекта — один под XAML прототип (с фейковым игровым API), второй — уже сама игра (или её UI часть использующая игровой API), которая просто импортирует XAML и возможно какие-то C# файлы.
Краши — к счастью, их давно искоренили. Но да, за эти годы я репортил десятки тикетов по крашам — всё оперативно устраняли. Включая самые загадочные случаи. Багтрекер у них публичный (некоторые баги репортят приватно).
Исходники полные на C++ они предоставляют при per project лицензии.
Я не думаю, что они забросят вдруг свой продукт или задушат его неразумными расценками на лицензии — он с каждым годом только набирает популярность. Их burnrate достаточно низкий — это небольшой офис в Мадриде да зарплата нескольким сотрудникам… Учитывая, сколько лет они тянули проект с нуля без какого-либо дохода (попробуйте реимплементировать WPF со всеми его неожиданными нюансами — это титаническая работа на несколько лет, прежде чем его можно будет предоставлять публике и тем более брать какие-то деньги) — не могу представить, чтобы они его вдруг забросили. Но самое главное, проект уже дорос до стадии, когда в общем-то это стабильная in-place замена WPF с поддержкой уймы платформ — но при этом отлично (безумно!) оптимизированная, чтобы игры не имели микрофризов и нагрузка на CPU/GPU была минимально возможной, с максимально качественным рендерингом векторной графики и текста, и множеством других фич, которыми сам WPF похвастаться не может (например, PPAA сглаживание, экстеншены для эффектов отрисовки текста, удобный внешний профайлер+инспектор, поддержка горячей перезагрузки, 3D-расширения и т. д.).
Что касается стоимости — кроме бесплатной лицензии для инди, лицензия на средний проект раньше стоила несколько тысяч евро, а для AAA игр (с бюджетом в 10+ млн евро или около того) около десятка тысяч евро. Но многое зависит от числа поддерживаемых платформ. Выше tangro спросил насчёт стоимости лицензии — я написал разработчикам этот вопрос и отпишусь, когда получу ответ.
NoesisGUI использовать в разработке видеоигр на самом деле удобно — особенно если вам уже знаком WPF/XAML/Blend, т. к. по сути дела это оно и есть. Можно почитать множество отзывов из Unity Asset Store. К слову, для последней игры я разработал свой игровой движок и пишу код UI на XAML как обычное WPF Application (код игры в опенсорсе (включая сотни XAML файлов/C#/шейдеры HLSL/графика/звуки/т. д.), можно посмотреть все ~0.5 млн строк кода и увидеть как всё организовано). Код XAML (равно как и сопутствующий ему C# код) автоматически используется as is и поддерживает горячую перезагрузку (в принципе сам движок заточен на горячую перезагрузку всего и вся, ну и на моддинг — фактически сама игра это мод к движку). В итоге процесс разработки и отладки очень быстрый, так что мне даже не приходится использовать XAML Designer.
Но обычно просто делают два параллельных проекта — один под XAML прототип (с фейковым игровым API), второй — уже сама игра (или её UI часть использующая игровой API), которая просто импортирует XAML и возможно какие-то C# файлы.
Краши — к счастью, их давно искоренили. Но да, за эти годы я репортил десятки тикетов по крашам — всё оперативно устраняли. Включая самые загадочные случаи. Багтрекер у них публичный (некоторые баги репортят приватно).
Исходники полные на C++ они предоставляют при per project лицензии.
Я не думаю, что они забросят вдруг свой продукт или задушат его неразумными расценками на лицензии — он с каждым годом только набирает популярность. Их burnrate достаточно низкий — это небольшой офис в Мадриде да зарплата нескольким сотрудникам… Учитывая, сколько лет они тянули проект с нуля без какого-либо дохода (попробуйте реимплементировать WPF со всеми его неожиданными нюансами — это титаническая работа на несколько лет, прежде чем его можно будет предоставлять публике и тем более брать какие-то деньги) — не могу представить, чтобы они его вдруг забросили. Но самое главное, проект уже дорос до стадии, когда в общем-то это стабильная in-place замена WPF с поддержкой уймы платформ — но при этом отлично (безумно!) оптимизированная, чтобы игры не имели микрофризов и нагрузка на CPU/GPU была минимально возможной, с максимально качественным рендерингом векторной графики и текста, и множеством других фич, которыми сам WPF похвастаться не может (например, PPAA сглаживание, экстеншены для эффектов отрисовки текста, удобный внешний профайлер+инспектор, поддержка горячей перезагрузки, 3D-расширения и т. д.).
Что касается стоимости — кроме бесплатной лицензии для инди, лицензия на средний проект раньше стоила несколько тысяч евро, а для AAA игр (с бюджетом в 10+ млн евро или около того) около десятка тысяч евро. Но многое зависит от числа поддерживаемых платформ. Выше tangro спросил насчёт стоимости лицензии — я написал разработчикам этот вопрос и отпишусь, когда получу ответ.
Спасибо за столь развёрнутый ответ.
Насколько я вижу из middleware для UI сейчас многие юзают Coherent (https://coherent-labs.com/). Они зашли с другой стороны, через html5/css. Это выглядит как более удобный для дизайнеров инструмент вёрстки UI, с Xaml всё же не все знакомы. Но у него теже проблемы — платный middleware с сорцами за приличные деньги и периодическими проблемами со стабильностью.
Так например Unreal Engine 4 вообще позволяет отказаться от использования сторонних продуктов и делать UI на своём техе. На нём и весь редактор их собственно сделан.
Про Unity не знаю, но выглядит так что и они к этому пришли/придут, это общее движение всех движков — позволить отказаться от сторонних библиотек.
Краши — к счастью, их давно искоренили.
К сожалению это невозможно, пока продукт развивается. Даже в их багтрекере в этом месяце есть свежие закрытые краши.
Мне кажется что тут основная проблема в том что в отличие от движков, типа UE4 или Unity аудитория таких проектов существенно меньше и краши находятся реже. И соответственно вероятность столкнуться с ним самому существенно выше.
P.S.: Я не хочу сказать что конкретно Noesis GUI плохой. Он меня как раз очень порадовал скоростью работы их сайта с примерами (в отличие от не расторопного семпла калькулятора у Uno). Но это общее впечатление от каждого middleware с которым довелось поработать.
Я очень рад поделиться своим опытом!
Coherent, как и прочие решения на HTML5/CSS, набрал популярность благодаря подкупающей доступности и лёгкости разработки. Но, т. к. это по сути своей браузерный движок Chromium, получаем все плюсы и минусы веб-интерфейсов. Главные из которых — слабая оптимизация (те же микрофризы), аппетит на ОЗУ, проблемы со стабильностью, а также зоопарк всевозможных технологий, накопленный за годы развития HTML/CSS.
Также, думаю, сравнивать векторную библиотеку с Chromium (пусть и имеющий поддержку SVG), бессмысленно. Это принципиально разные подходы. Равно как и разница подходов к разработке. У HTML5 были совсем другие цели. WPF изначально разрабатывали достаточно умные люди как решение для разработки сложных анимированных десктопных интерфейсов, сделав очень хороший и логичный фреймворк. В свою очередь, NoesisGUI разрабатывали как высокооптимизированный middleware практически полностью имплементирующий WPF/XAML, при этом с упором на плавную работу, низкое потребление памяти и ресурсов CPU/GPU.
Что касается нативный компонентов интерфейса в UE4 и Unity — они серьёзно ограничены в своих возможностях и удобстве разработки. Во многом это из-за отсутствия поддержки какого-либо markup language. Я разрабатывал игру на Unity на тогда новом Unity UI, сразу после завершения проекта использовавшего NoesisGUI (тоже в составе Unity), и был просто в отчаянии от того, насколько вся эта возня с компонентами/префабами Unity неудобна именно в плане разметки UI и привязки данных, а также в плане удобства взаимодействия с коллегами (попробуйте смержить!). Для меня лично гораздо приятней и быстрее набирать код руками.
XAML + MVVM = очень мощный подход, позволяющий писать сложные интерактивные интерфейсы действительно быстро (посмотрите упомянутый выше код нашего проекта на Гитхабе — всё написано одним программистом, ~0.5 млн строк за несколько лет, очень много UI, а ведь мне ещё нужно всё остальное делать; к тому же игра — сетевая и на своём движке, почти всё приходилось писать с нуля).
Что касается крашей — я просто отметил из своего опыта, что крашей я давно не видел, при этом у нас более 200,000 довольных игроков за последние два года. Дальше будет только лучше, ведь библиотека наконец-то используется в AAA-играх, не считая множество более мелких тайтлов и портов легаси WPF-приложений. В багтрекере вижу только редкие случаи и в основном они касаются Unity Editor или каких-то недавно добавленных платформ. А вот Windows/DirectX/OpenGL — всё уже давно отполировано до блеска и стабильно практически как WPF, я думаю.
Но, если говорить о крашах в принципе, точно такая же проблема наблюдается и с нативным UI в популярных игровых движках, и в любом другом middleware… (к слову, Unity в своё время (2015-2017) меня просто вынудил начать писать свой движок, их CEO даже опубликовал пост в блоге компании из-за вакханалии с багами в каждом билде)
Noesis не менее зрелый, чем тот же Coherent, но построен на гораздо более прочном и предсказуемом фундаменте — команда Noesis очень маленькая и они писали практически весь код с нуля (даже не используя сторонние библиотеки в своём ядре, насколько я помню), покрывая его тестами, и поэтому знают его вдоль и поперёк.
Для меня лично самое важное заключается в том, что NoesisGUI позволяет применять накопленный опыт WPF/XAML, без каких-либо исключений и компромиссов. И это не только игровой middleware, а так же полноценная кроссплатформенная имплементация WPF — можно использовать в десктопных ОС, на консолях, смартфонах, даже в вэб. Недавно появились официальные NuGet пакеты, обновили стандартные контролы, сделав их симпатичными, сделали отличную документацию.
Конечно, жаль, что это не бесплатный опенсорс проект, но понять можно — люди трудились годами, живя на сбережения и инвестиции, поставив всё на этот проект — и теперь пожинают заслуженные плоды. Здоровая конкуренция (та же Avalonia очень радует прогрессом) умерит жадность всех разработчиков таких библиотек!
Coherent, как и прочие решения на HTML5/CSS, набрал популярность благодаря подкупающей доступности и лёгкости разработки. Но, т. к. это по сути своей браузерный движок Chromium, получаем все плюсы и минусы веб-интерфейсов. Главные из которых — слабая оптимизация (те же микрофризы), аппетит на ОЗУ, проблемы со стабильностью, а также зоопарк всевозможных технологий, накопленный за годы развития HTML/CSS.
Также, думаю, сравнивать векторную библиотеку с Chromium (пусть и имеющий поддержку SVG), бессмысленно. Это принципиально разные подходы. Равно как и разница подходов к разработке. У HTML5 были совсем другие цели. WPF изначально разрабатывали достаточно умные люди как решение для разработки сложных анимированных десктопных интерфейсов, сделав очень хороший и логичный фреймворк. В свою очередь, NoesisGUI разрабатывали как высокооптимизированный middleware практически полностью имплементирующий WPF/XAML, при этом с упором на плавную работу, низкое потребление памяти и ресурсов CPU/GPU.
Что касается нативный компонентов интерфейса в UE4 и Unity — они серьёзно ограничены в своих возможностях и удобстве разработки. Во многом это из-за отсутствия поддержки какого-либо markup language. Я разрабатывал игру на Unity на тогда новом Unity UI, сразу после завершения проекта использовавшего NoesisGUI (тоже в составе Unity), и был просто в отчаянии от того, насколько вся эта возня с компонентами/префабами Unity неудобна именно в плане разметки UI и привязки данных, а также в плане удобства взаимодействия с коллегами (попробуйте смержить!). Для меня лично гораздо приятней и быстрее набирать код руками.
XAML + MVVM = очень мощный подход, позволяющий писать сложные интерактивные интерфейсы действительно быстро (посмотрите упомянутый выше код нашего проекта на Гитхабе — всё написано одним программистом, ~0.5 млн строк за несколько лет, очень много UI, а ведь мне ещё нужно всё остальное делать; к тому же игра — сетевая и на своём движке, почти всё приходилось писать с нуля).
Что касается крашей — я просто отметил из своего опыта, что крашей я давно не видел, при этом у нас более 200,000 довольных игроков за последние два года. Дальше будет только лучше, ведь библиотека наконец-то используется в AAA-играх, не считая множество более мелких тайтлов и портов легаси WPF-приложений. В багтрекере вижу только редкие случаи и в основном они касаются Unity Editor или каких-то недавно добавленных платформ. А вот Windows/DirectX/OpenGL — всё уже давно отполировано до блеска и стабильно практически как WPF, я думаю.
Но, если говорить о крашах в принципе, точно такая же проблема наблюдается и с нативным UI в популярных игровых движках, и в любом другом middleware… (к слову, Unity в своё время (2015-2017) меня просто вынудил начать писать свой движок, их CEO даже опубликовал пост в блоге компании из-за вакханалии с багами в каждом билде)
Noesis не менее зрелый, чем тот же Coherent, но построен на гораздо более прочном и предсказуемом фундаменте — команда Noesis очень маленькая и они писали практически весь код с нуля (даже не используя сторонние библиотеки в своём ядре, насколько я помню), покрывая его тестами, и поэтому знают его вдоль и поперёк.
Для меня лично самое важное заключается в том, что NoesisGUI позволяет применять накопленный опыт WPF/XAML, без каких-либо исключений и компромиссов. И это не только игровой middleware, а так же полноценная кроссплатформенная имплементация WPF — можно использовать в десктопных ОС, на консолях, смартфонах, даже в вэб. Недавно появились официальные NuGet пакеты, обновили стандартные контролы, сделав их симпатичными, сделали отличную документацию.
Конечно, жаль, что это не бесплатный опенсорс проект, но понять можно — люди трудились годами, живя на сбережения и инвестиции, поставив всё на этот проект — и теперь пожинают заслуженные плоды. Здоровая конкуренция (та же Avalonia очень радует прогрессом) умерит жадность всех разработчиков таких библиотек!
Грустно.
Хочу переносить проект с Borland С++ Builder 5. Какие же там сказочно легкие бинарники получались! У меня в ПО чтение с СОМ-порта, СУБД, много данных, графики (TeeChart), отчеты(Fastreport), локализация на 4 языка.
Второй год ломаю голову. То ли на Qt, то ли на Winforms, то ли UWP. Задрали блин с развитием технологий. Не знаешь, что выживет через 10 лет.
Вот как выжить в таком хаосе технологий?
P.S. Только Windows, только С++, нужна поддержка Windows 7.
Хочу переносить проект с Borland С++ Builder 5. Какие же там сказочно легкие бинарники получались! У меня в ПО чтение с СОМ-порта, СУБД, много данных, графики (TeeChart), отчеты(Fastreport), локализация на 4 языка.
Второй год ломаю голову. То ли на Qt, то ли на Winforms, то ли UWP. Задрали блин с развитием технологий. Не знаешь, что выживет через 10 лет.
Вот как выжить в таком хаосе технологий?
P.S. Только Windows, только С++, нужна поддержка Windows 7.
1. Windows 7 официально Microsoft больше не поддерживается (насколько знаю).
2. А надо ли переносить, может, просто обновиться? Мало-помалу C++ Builder пилится.
Я сам на Delphi, но вижу что в каждом релизе что-то добавляют/подправляют в части C++. David Millington — бывший евангелист C++, сейчас Senior Product Manager в Embarcadero. Вот Roadmap на 2021 год:
2. А надо ли переносить, может, просто обновиться? Мало-помалу C++ Builder пилится.
Я сам на Delphi, но вижу что в каждом релизе что-то добавляют/подправляют в части C++. David Millington — бывший евангелист C++, сейчас Senior Product Manager в Embarcadero. Вот Roadmap на 2021 год:
Замена — новый Билдер.
Почему?
Почему?
- Почему то с СУБД, компоненты дельфи/СБ работают быстрее. С Оракле — просто в разы, даже немного стыдно стало перед заказчиком за переписывание и такой тормозной ЮИ (
- TeeChart для .NET придется докупать отдельно (289$), адекватный _и быстрый!_ бесплатный аналог мне не попался — предлагайте
- Вместо Fastreport для NET придется либо покупать FR.NET (еще 279$), либо монстрообразный SQL Server Reporting Services только для MS SQL, либо искать что либо недохлое на гитхабе (без конверсии ес-но)
- С локализацией проблем почти не будет. Равные проблемы в обоих случаях
- Раз Windows7, никаких кардинальных нововведений от МС. Официально многое поддерживается (вроде C++/WinRT) c Win10.1803, хотя я мелочи тестировал на WPF .Core 3.1 на Win7-x64 и работало, офлист
Для локализации в Delphi я давно сделал был собственный прибамбас. Работает быстро, место занимает мало. Но недавно появился Better Translation Manager, там есть удобная форма для переводов. Если делать с нуля, возможно оно лучше.
Спасибо за рекомендации.
Embarcader'ы я трогал. Вызывали они у меня лишь чувство разочарования.
Получился какой-то гроб на колесиках ИМХО.
А в случае с .NET, очень удивило малообразие сторонних опенсорсных библиотек для отрисовки графиков и генерации отчетов.
Даже под Qt всего этого полно.
Embarcader'ы я трогал. Вызывали они у меня лишь чувство разочарования.
Получился какой-то гроб на колесиках ИМХО.
А в случае с .NET, очень удивило малообразие сторонних опенсорсных библиотек для отрисовки графиков и генерации отчетов.
Даже под Qt всего этого полно.
Какой UWP для Windows 7?
Мне всё таки кажется, что обезьянок нужно в обратном порядке поставить.
Кто будет использовать WinUI 3, если поддерживается только начиная с Win 10 1809?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
WinUI 3 — Новая эра разработки под Windows