2023 год Windows Forms или WPF?

Читаю раздел материалов microsoft по потокам данных и вижу, что хоть статьи все и помечены датой из 2023 года, но примеры все для Windows Forms. Почему не для WPF? Интересно, какой процент Windows Forms и WPF в новых приложениях? WPF оказался чем-то хуже Windows Forms и так и не стал преобладающей технологией? И какой прогноз на будущее в этом плане?
Я просто не в курсе событий, хоть и интересуюсь темой в частном порядке)

0

Сообщение от Andrey-MSK Сейчас пока это модно

В данном случае вопрос в деньгах, а не в моде - это куда дешевле, чем держать штат разработчиков отдельно под Мак, отдельно по Линукс, отдельно под Windows. Пользователи, правда, не всегда довольны подобными решениями (судя по некоторым маковским форумам), т.к. приложения начинают выглядеть непривычно, особенно, когда уже существующее приложение заменяют электрон-версией, но компании всё равно продолжают продавливать эти решения (видимо, реально сильная экономия ресурсов).

0

Сообщение от kotelok это куда дешевле, чем держать штат разработчиков отдельно под Мак, отдельно по Линукс, отдельно под Windows.

Возьмём для примера Autodesk Maya - на всех ОС она выглядит одинаково, так как в качестве UI используется Qt и не надо три штата специалистов, всё пишется на Qt/C++. Что мешает товарищам из MS сделать тоже самое для NET?

1

Сообщение от Andrey-MSK на всех ОС она выглядит одинаково

Ну вот пользователям это не особо нравится, т.к. им привычнее, когда приложение выглядит как они привыкли на своей ОС. Хотя, даже в рамках дефолтных приложений Винды есть варианты которые не вписываются в общий стиль и просто выглядят так, как им "удобно".

Qt да, вариант. Но он тоже не даёт 100%-й нативности ни в поведении, ни во внешнем виде. Например, десктопный (Виндовый) клиент Телеграма, который реализован на Qt, но у которого даже всплывающие (по правой кнопке) меню реализованы не через нативные виндовые меню, а через эмуляцию этого меню в отдельном прозрачном окне. Как результат - при правом клике и появлении меню, основное окно телеграма теряет фокус (со всеми соответствующими визуальными эффектами и последующим проглатыванием одного клика). Ну или у некоторых Qt-приложений, которые я видел, в принципе не работала дефолтная логика прилипания окон к краям экрана или вытягивания окна из максимизированного состояния за заголовок.

Но опять же - компании продолжают выбирать Qt т.к. это, как и Электрон, вариант минимизировать кодовую базу и количество разработчиков (хоть и ценой немного непривычного UI для пользователей).

1

Сообщение от reti Мне не нужен красивый интерфейс. Мне нужен надежный инженерный софт для связи с контроллерами или микроконтроллерами.

Сообщение от titan4ik таких применений может быть много (!!!) Очень много! И при наличии таких технологий, людей, которые их бы использовали, было бы много. То есть, большое число специалистов предметной области могли бы делать прикладные программы для себя и коллег, не отвлекая высококвалифицированных специалистов программистов от их высоких чаяний. (WF, всё-таки, не мыслился таким продуктом. И, после появления WPF, WF как бы был уже технологией вчерашнего дня.

Сообщение от Uswer но всегда ли это нужно узкому специалисту?

Я же сразу за это написал:

Сообщение от Элд Хасп Если какое-то техническое, инженерное приложение. Где визуал не важен, то Форм-приложения встречаются часто.

Для большинства "технарей инженеров" не требуется красивого визуала, им концептуально ближе и понятнее ПП (процедурное программирование), ООП часто воспринмается как "необходимое зло", возможностей Форм со всей логикой в Code Behind хватает "выше головы". Никакого XAML, MV* им не нужно - это только лишнее усложнение для них.
Это не хорошо, но это и не плохо. Такова реальность. И действительно как отметил reti, промышленное программирование - это очень коммерческое и часто очень высокооплачиваемая область программирования. Я сталкивался со случаями (буквально пару неделю назад последний был) когда компания (инагент) продаёт софт, который может сделать один разработчик "на коленке" за полмесяца-месяц по цене в десятки и сотни килобаксов.

Но в тоже время reti и упускает такой момент. Сделанная такая программа на Формах будет прекрасно работать. Но купят её совсем по иной цене, чем тоже самое под нормальным GUI. Условно заплатила компания reti за софтину 1-2 килобакса, добавила свой современный GUI, который предаст ей законченный коммерческий вид и будет продавать за десятки и сотни килобаксов. таки случаи очень часты. Последний с каким столкнулся именно из этой серии. Посвяти мой знакомый немного усилий приданию нормально вида GUI своей софтине, то его труд был бы оценён раз в десять выше.
Другое дело, что большинство "инжереных разработчиков" - это всё же разовые заказы или даже работа в штате заказчика, пользователя созданной софтины. О продажах нескольким Заказчикам речи , в принципе, не идёт.

2

Сообщение от aenye Популярны для небольшого размера приложений под десктоп сейчас электрон (порог входа - наличие глаз и 1 день опыта на фронтЕ) и qt (порог входа повыше).

Не понял - а qt можно с c#?

Добавлено через 5 минут
Точнее так - я-то нагуглил, что можно. Но это точно хороший вариант?

Добавлено через 5 минут
Мда, нужно посмотреть этот электрон и qt. А то у меня идиосинкразия и к WPF и к WF.

0

Сообщение от titan4ik Не понял - а qt можно с c#?

Возможно и есть какой-то тулкит или либа для решетки, но в основном - это c++

Добавлено через 13 минут

Сообщение от reti Вы даже не представляете сколько может стоить софт для управления станком. Скорее всего, вы просто рыбачите не в рыбном месте)

Возможно. Но предположу, что Вы не представляете, сколько стоит софт не для управления станком) Поэтому и 0%, даже если представить, что одно Ваше решение для станка стоит 10 миллионов долларов.

Мне кажется, что более удачным примером по объему рынка были бы какие-нибудь IDE. Но тут (сюрприз-сюрприз) на сцену выходит JetBrains с новым UI и VS Code. Угадайте, на основе какой технологии они разработаны.

Сообщение от reti Эээ... Ну как бы у меня примерно 100% новых приложений на WF

Значит, вы просто нашли себе рыбное место, но на общем фоне это ничего не меняет.
Объем рынка точечных решений на WF и того же веба совершенно несопоставим.

0

Сообщение от aenye Угадайте, на основе какой технологии они разработаны.

Вроде в версии 2022.2.2 (в текущей EAP версии) уже Avalonia для нового UI используется, для старого - Java.
При этом новая версия умеет работать с HI DPI экранами.

Ща покажу на примере (4K монитор).
Первая картинка - как выглядит список проектов на версии 2021.3.4 со старым UI.
Вторая картинка - 2022.2.2. Разница налицо (текст

И это все на Manjaro.

1

Вообщем, я верю, что Avalonia закроет этот кроссплатофремнный GUI-gap .NET-а.

0

Сообщение от aenye Угадайте, на основе какой технологии они разработаны.

Сообщение от IamRain уже Avalonia для нового UI используетс

Дак Avalonia это практически тот-же WPF, только кроссплатформенный, так что все заявления о мёртвом Desktop просто в никуда...

Добавлено через 1 минуту

Сообщение от IamRain Вообщем, я верю, что Avalonia закроет этот кроссплатофремнный GUI-gap .NET-а.

Если майки его официально возьмут под крыло, то получится весьма и весьма интересная штука

0

Вложения.

Миниатюры

   

0

Сообщение от Andrey-MSK Если майки его официально возьмут под крыло, то получится весьма и весьма интересная штука

Да им это и не нужно. У JetBrains недавно был .NET-day, можно глянуть на состояние дел, был один доклад по Avalonia.
По скринам видно, что текст пути к проекту в списке проектов уже нормально отображается. It works! (Manjaro + Arch tested)

0

Сообщение от IamRain Да им это и не нужно.

Я имею ввиду встроить в VS, а не как расширение устанавливать. Тогда и интеграция будет лучше и сообщество начнёт лепить отчёты по ошибкам.

0

Сообщение от Andrey-MSK Я имею ввиду встроить в VS,

Ну это да. JetBrains, получается, уже дважды удачно втиснулась в .NET - первый раз написав Resharper, второй раз - написав Rider.
Плюс сторонняя Avalonia созрела.
Как я рад, что у нас есть Open Source и divesity.

0

Сообщение от IamRain Вообщем, я верю, что Avalonia закроет этот кроссплатофремнный GUI-gap .NET-а.

Зашёл на офф-сайт Авалонии, скачал первое приложение из раздела 'Showcase', установил на Win-10, запустил, получил расход памяти 1.6ГБ. Далее, просто немного увеличил размер окна - память процесса подскочила до 2.7ГБ и там и осталась (т.е. никакие новые данные не подгружались, никакие окна не открывал, т.е. чисто на отрисовке UI). Это к вопросу "электрон прожорливый". На деле - минимальное приложение с одним окном на Электроне, после (мгновенного) запуска под Виндой занимает в памяти ~250МБ, на Авалонии ~180МБ. При этом, если в тот же Электрон пытаться врендерить страничку с тысячей элементов и потом модифицировать их (в DOM-дереве) по десять-двадцать раз в секунду, то, как и любой UI, он потребляет примерно одно ядро в попытках сделать перерисовку максимально быстро, при этом доп-память не потребляет вовсе.

Я это не к тому, что какая-то платформа хуже/лучше в плане памяти/производительности, а скорее к тому - что и на Электроне, и на Qt, и на Авалонии, можно написать как хороший код, так и откровенно некачественный, который будет и тормозить, и память потреблять без меры (и не убирать за собой).

Так же, судя по докладу с Ютуба от разработчиков обозначенного выше приложения - это реальное коммерческое приложение, которое изначально было на WPF и которое успешно портировали под MacOS и Ubuntu путём перехода на Avalonia. Ну и по тому же докладу - у них возникли настолько серьёзные проблемы с реализацией кроссплатформенной многооконности и попапов, что было решено полностью от всего этого отказаться, т.е. все менюшки, комбобоксы и диалоговые окна открывают только в границах основного окна (речь про конкретное приложение на Авалонии, а не про Авалонию в целом). При реализации на Электроне, кстати, возникают ровно те же проблемы и они ровно так же либо не решаются вовсе (отказываемся от удобной многооконности), либо решаются причудливыми костылями. Да и на Qt ситуация не лучше. В VSCode, кстати, по тому же пути пошли - менюшки все внутри окна и если окном маленькое, они стараются хоть как-то в него вписаться.

2

Сообщение от kotelok отказываемся от удобной многооконности

Ну тогда подход один - три команды разработчиков UI под каждый тип ОС, и тогда получим красивый (с блэкджеком и попаппами ), адекватный UI в логике ОС...

1

Сообщение от Andrey-MSK три команды разработчиков UI под каждый тип ОС

Три? В том же докладе есть фрагмент, где один из разработчиков сетует, мол "этих линуксов такое количество, что мы остановились на поддержке только Ubuntu". Ну т.е. да, понятно, что команде Линукс-разработчиков можно озвучить требование поддержки Астры, Редоса, Убунты, АльтЛинукса и ещё кучки чего, и пущай они там страдают, добиваясь на всех системах и всех типах рабочих столов максимально нативного поведения. Но что-то мне подсказывает, что это будет ну очень больно. Но тут, как выше отмечалось - вопрос в целевой аудитории. Т.е. если это разработка под конкретного заказчика, то там и требования будут конкретные (в т.ч. по ОС). А вот если это приложение на широкую аудиторию (да даже просто ориентировка на российский гос-сектор, где в очередной раз пытаются принудить к переходу на Линкус), то там конечный пользователь может выбирать между разными вариантами Линуксов (и визуально они заметно отличаются).

Сообщение от Andrey-MSK три команды разработчиков UI под каждый тип ОС

Ну и да - очень дорого ).

2

Сообщение от kotelok и визуально они заметно отличаются

Основные рабочие столы в Linux это KDE и GNOME, остальное всё от лукавого...

0

Сообщение от Wolfdp вставлю пять копеек. Что WF, что WPF имеют серьезный изъян -- они только под винду. Это пипец как критично во многих случаях выбора "на чем писать", а в текущий реалиях кроме windows, macOS и linux зачастую ещё нужен android и iOS.

Универсального решения нет. Хочешь качественно и красиво - делай под каждую систему отдельное приложение.

2023 год Windows Forms или WPF?
WPF конечно - нет ограничений по созданию графического интерфейса. Именно из за этого отошел от Windows Forms.

Добавлено через 5 минут

Сообщение от Wolfdp Технически расставлять элементы мышкой и кликать по свойствам можно в обоих технологиях, я как-то не уверен что WF тут имеет хоть какое-то преимущество.

Windows Forms конечно проще и быстрее. Если приложения простые - то стоит остановится на Windows Forms.

2

Сообщение от Козадоев Windows Forms конечно проще и быстрее.

я либо не понимаю про что речь, либо меня пытаются убедить что toolbox и properties в wpf проекте работают каким-то невероятным образом медленее.

Ну вот самый простой пример -- форма логирования:
- добавить 2 лейбы драгендропом с toolbox на окно
- два тексбокса
- кнопка 1 шт
- зайти в text|content, удалить/написать нужное. Всякие хоткеи аля F2 приветствуются, но по факту -- лезем в properties
- кликнуть по кнопке два раза и написать обработчик, который обращается к двум textbox по имени.

Я бы даже сказал, что в WPF редакторе как минимум есть привязка к краю прям в графическом дизайнере, что несколько упрощает таскание, а не постоянно лезть в свойства и выставлять от нужно края. Можно на словах пример, который бы показывал что вот так на WF легко и быстро, а на WPF -- нельзя и нужно делать по другому?

3

Козадоев, Wolfdp, В WPF вообще ничего не надо якорить, оно само растянется и сожмётся когда надо и куда надо. Задал отступы (Margin) и готово

2