Комментарии 226
При уважении к желанию Сэма (автора), есть прекрасный тост (из известного фильма) про желания и возможности.
Если изначально UI либы созданы и поставляются как наборы DLL и ресурсов, то желание запихнуть все в один EXE-шник, а затем динамически распаковывать звучит так себе.
Получается: либо свое, либо узкий набор решений.
Странные утверждения, я бы сказал. Начиная от приложения, которое можно статически слинковать с MFC и в то же время оно будет весить несколько килобайт, до неотключаемой рамки у скайтеровского приложения. Да и остальное не лучше. Я бы сказал, это всё не случайные ошибки, а глубокое непонимание сути. MFC это не GUI-библиотека, а фреймворк для поддержания полного жизненного цикла документа, гуишная часть там вспомогательная, как и замена STL, если это понимать, можно не строить иллюзий по поводу небольшого размера (хотя, конечно, он всё равно будет сильно меньше, чем у Хромиума, гы-гы). Что касается Скайтера, он не занимается никакими рамками.
ImGui - шедевр, каких мало, но я бы не сравнивал его с Qt или WPF, это соврешенно разные весовые категории. ImGui идеально решает задачу отображения вспомогательных данных, простых кнопочек и крутилок конфигов, но сложные интерфейсы ещё и с высокой степенью кастомизации я бы на нём делать не стал.
что может быть более кастамизируемо чем прямое взаимодейтсвие с шейдерами и всем остальным конвейером рендеринга без каких либо промежуточных API OS?))
Ну, на qt всё это тоже есть и с очень удобными обертками и интегрировано в виджеты, даже бэкенды на свой вкус можно выбрать а не только вулкан, только это надо ещё придумать гуй который нельзя сделать тем что есть и нужно лезть на этот уровень
в qt можно зарендерить чтоб кнопка при нажатии например взрывалась на партикли? если да то я этого реально не знал. И не совсем понял про "только вулкан" imgui поддерживает вообще любой рендерер который умеет треугольники рисовать. Ну и я не спорю что для больших приложений qt гораздо проще и быстрее использовать, по крайней мере пока что.
например взрывалась на партикли
очень жаль, что это тоже называют под одну гребенку GUI, просто когда обсуждают тот или иной движок, одни подразумевают возможность это сделать а другие даже не задумываются об художественных изысках и думают о том, например, как бы удобнее было делать элементы, взаимное расположение и размер которых взаимосвязаны сложным образом, а третьим подавай удобный функционал с visivyg биндингами с данными или синтаксическим сахаром для удобства описания этого.
А ведь изначально api/библиотеки для gui буквально занимались только доставкой контента (текста, изображений и компонентов взаимодействия) на экран рабочего стола... а сам контент пусть разработчик создает, зачем это тянуть в библиотеку? Qt например вырос не в просто движок для GUI но и сложную и многофункциональную (для своего времени) систему по работе со всем, начиная с работой с сетью или базами данных и заканчивая элементальными типами данных типа строки.
Такое не только qt может и тем более не только imGUI. В Delphi fmx тоже выбирается бэк. Gdi, opengl, directx, direct2d, metal, opengles, skia. И поддерживаются шейдеры, так что можно не только взорвать кнопку, но и поджечь рядом стоящие.
Как у ImGui с accessability? Она довольно далека от нативных элементов, всё-таки. И как у приложения с её использованием с энергопотреблением? Если я пишу условный калькулятор или какой-нибудь генератор отчётов с двумя кнопочками и одной областью просмотра - не заставит ли это пользовательское железо раскочегаривать мощности GPU?
а наследников Borland C++ нет уже?
Судя по дельфи, создание UI в виндовс, это было совсем несложно. И ехешник единый можно получить
Оно около живое в виде Embarcadero RAD Studio, на бумаге выглядит очень интересно, но чёрт его знает как оно в жизни
Там вроде нативные контролы - то есть отпадает по критерию стилизации и темной темы. Вообще без этого критерия всё было бы гораздо проще. Ну или если бы нативные контролы поддержали стилизацию (это уже совсем мечты).
Там есть VCL и FireMonkey. Последний — кроссплатформенный (Windows, Linux, mac), поддерживает визуальные стили. VCL (нативные контролы) также поддерживает стили, есть тёмный стиль Windows 11, очень приличный (ставится через GetIt). У Delphi и C++Builder есть и бесплатные версии сейчас. Вообще технологически всё это очень приличное. Для меня всё выглядит так, будто Delphi / С++Builder в какой-то момент проиграла некую информационную войну. При этом технология не просто приличная, а прекрасная.
+ (Android, iOS) в том же FireMonkey
Студия в 2008 или каком году стала бесплатной, имею ввиду сначала экспресс, а потом комьюнити. А дельфи не могла себе этого позволить, видимо поэтому и проиграли. Жаль, VCL намного лучше убогого MFC
Мне ещё кажется, они до сих пор не научились в нормальное позиционирование и красивую подачу. Сейчас сайт "украсили" нейрокартинками чуть ли не в худшем их проявлении. Им бы нормальных спецов нанять в этой сфере, в т.ч. дизайнеров и т.д. Сравнить, к примеру, с JetBrains: как у них проработан сайт, как представлены продукты и т.д. Просто небо и земля.
JetBrains IDEшки появились не так давно, и работают на сравнительно современной графике, в то время как RAD Studio IDE создавалась ещё в 1995 году и до сих пор используется то же самое ядро, на том же VCL (Win32). Для современной красоты нужно отказываться от VCL и смотреть в сторону фреймворков, которые рендерятся на GPU (в RAD Studio это, например FMX). Однако, переписать всё, практически с нуля, выйдет в копеечку.
Тем не менее, функционал IDE крайне широк и тягается с MS VS. Имеет гибку настройку и ToolsAPI для плагинов. Ну и фреймворков для RAD Studio полно на любой вкус и цвет. Под мобилки, под полную кроссплатформу, под веб, под фуллстек веб, под IoT, под бэк. Которые тесно работают со средой разработки.
Я не про IDE, а про сайт. IDE выглядит нормально. Только есть глюки на HiDPI экранах: лично у меня белая полоса сверху при разворачивании на весь экран. Есть неудобности в редакторе, как по мне (например, поведение поиска), и это наследием тоже не оправдать, просто так сделано.
Но всё же я не про IDE, а про сайт, про презентацию продукта.
С маркетингом однозначно пока туго, но я думаю, что в какой-то момент займутся и этим, когда продукт дойдет до презентабельного состояния (как по внешнему виду, так и по фичам). В RAD Studio 12.2 Beta есть новшества связанные с IDE (NDA, рассказать не могу)
Я считаю, что продукт уже очень хороший и давным давно всё заслуживает :)
Мне просто кажется, что сейчас всем этим занимаются больше технари. Наверняка там есть дизайнеры, но как будто это всё по остаточному принципу.
Я помню, что раньше сайт Embarcadero был на Joomla сделан. Сейчас не знаю :)
Кстати, ваши комментарии и ответы по Delphi я давно приметил.
Сам я много лет старался хоть как-то поддерживать набор компонентов TBX (вы наверняка о них знаете). Мне на это давал добро их оригинальный разработчик. Но последнее время — всё, ресурсов на поддержку практически нет.
Ага, приходится во все темы влезать по Делфи, чтобы рушить закостенелые мнения о том, что Делфи не используется)
Я вот слышу про Delphi хорошее и интересное в комментариях, потом смотрю на количество вакансий...
Это был де-факто стандарт бизнес-приложений в 2000х, поэтому должно быть много вакансий на разгребание legacy 20-летней давности в гос и около-гос учреждениях, или конторах уровня "Рога и Копыта".
Да! Я всегда мечтал таким заниматься! И зарплаты в госах конечно мечта!
На одном старом месте моей работы до сих пор еще работают приложения на Delphi 6 и Visual Basic 6 ну и мои на Windows Forms и .net 4. И если я еще старался писать чистый код и фреймворк до сих пор официально поддерживается, не было бы импортзамещения они бы еще и лет 10 проработали - но вот первые два пункта это ужас ужас особено VB6 с инструкцией по установке на 12 листов и закрытыми кастомными компонетами закупленными в неведомые времена. Про код внутри молчу.
Но на самом деле даже несмотря на это вакансий почти нет, достаточно на тот же hh заглянуть Delphi 103 - C# 1382 - PHP 1500 - Go 1778. Разница больше чем на порядок, ну и в перспективе дальнейшее сокращение.
От легаси никуда не деться на любом инструменте. На C# или JS легаси кода не меньше. А про php вообще молчу. Так что, наличие легаси на Делфи не является сюрпризом.
Но никто не принуждает тебя заниматься легаси проектами. Достаточно в вакансии смотреть на используемую версию языка. Потому как она регулярно обновляется и по версии в вакансии можно многое узнать о компании.
Вакансий на Делфи больше
Вакансий на HH:
Delphi: 240 (-5) ~100k (30-240)
Pascal: 84 (-3) ~60k (30-200)
Python: 3867 (-29) ~60k (10-300)
C#: 2240 (-36) ~60k (19-200)
C++: 2738 (-44) ~80k (19-400)
Swift: 439 (-8) ~120k (35-300)
Java: 3623 (-15) ~75k (30-300)
Visual Basic: 102 (-7) ~88k (25-200)
Go: 1282 (-27) ~100k (0-300)
Ruby: 155 (+6) ~130k (20-350)
Kotlin: 1065 (-3) ~120k (35-350)
Rust: 126 (0) ~120k (40-360)
Fortran: 4 (0) ~0k (0-0)
Dart: 167 (-3) ~100k (20-350)
Flutter: 270 (-5) ~100k (0-350)
FireMonkey: 2 (0) ~100k (80-100)
Electron: 62 (-4) ~120k (50-350)
Lazarus: 12 (-2) ~60k (32-120)
React Native: 271 (-6) ~80k (17-350)
1С: 6717 (-38) ~67k (25-400)Я веду регулярную статистику по медианной зп. Здесь кол-во вакансий всего, разница со вчерашним днем, медианная зп, и вилка всех вакансий, где указана зп в рублях.
Новые версии не имеют полной обратной совместимости со старыми проектами. Например, в нашей компании, есть как легаси проект (для Д7), так и куча новых проектов (для мобилок и не только) на свежей версии Д12 2024 года.
Все равно разрыв на порядок и более с мейнстримными языками. PHP кстати специально не включаете? Ну и более низкая медиана может как раз свидетельствовать что технология более жива и набирают больше джунов.
Тем не менее, вакансии на Делфи есть и не плохо оплачиваются. Да, их мало, никто с этим не спорит. Но и активность владельцев языка и среды началась совсем недавно. Качество кроссплатформенного инструмента возросло тоже сравнительно недавно (всё это в районе 5-6 лет).
Ну и доказывать, что делфи "мейнстримный" в данный момент никто не собирается.
Всего несколько тезисов с моей стороны:
делфи вполне актуален и позволяет решать много современных задач
на нём удобно и приятно работать
активность сообщества приемлемая, чтобы тебя услышали, помогли или ты мог помочь
разработчики среды и языка имеют тесные контакты с сообществом (напрямую в телеге можно пообщаться)
общедоступный трекер багов и фич имеется
вебинары по нововведениям или другим темам проводятся регулярно и даже на русском языке, представителями инструмента в России
Я не пытаюсь и не пытался оспорить эти тезисы. Количество вакансий еще не говорит что язык прямо замечателен, но определенные перспективы в плане дальнейшей карьеры показывает. Понятно что страшное легаси есть везде но если выбирать из 200 вакансий и из 2000 шанс найти что-то новые и интересное без легаси или приемлемое по другим параметрам выше в 2000. Есть еще хайповые языки на явном взлете вроде Rust но тут уже как угадаешь. Опять же легаси на Go или Rust явно намного меньше. Размер сообщества - это еще и количество сторонней документации, сторонних библиотек и компонентов.
Я-то в целом смотрю так, что как говнокод таки хороший код можно написать практически на любом языке - это инструменты, а не идолы.
Ну и на английском читаю документацию свободно и спросить могу при нужде.
У меня есть планы (которые весьма вероятно не реализуются ибо время силы и далее по списку включая меньше тратить время на обсуждения на хабре)) ) десктопного пет-проекта думал и о Delphi но тут еще останавливает такой фактор, как закрытость и платформы и инструментария.
Актуальный в наше время вопрос - как здесь с санкциями?
тут еще останавливает такой фактор, как закрытость и платформы и инструментария.
В отличие от других инструментов (например, Qt или .Net (хотя вроде он уже имеет открытую версию)), тут код открыт. Ты можешь проследить работу своей программы от точки входа и увидеть каждую строку, которая выполняется. В этом нет никакой закрытости. Закрыт код IDE и компиляторов, а код штатных фреймворков и RTL открыт. И на него даже можно влиять во время разработки.
Санкции влияют только на способ оплаты. Но в России есть официальные ритейлеры, которые без проблем и особых наценок продают ключи. Т.е. компания не участвует в санкциях.
Да тут многих языков нет, они тут только для сравнения. Хотя база статистики пополняется уже давно.
Вы правы, но там и без дизайна много проблем с сайтом. Вики часто ссылается непонятно куда, т.е. ссылки "мертвые" или вовсе лежит. MSDN последнее время тоже, конечно, не супер. Но там можно получить любую инфу, причем свежую, т.е. если в Windows 10 вышло обновление по апи, оно будет. Здесь же..приходится гуглить, спрашивать по форумам.
В Delphi нативные контролы поддерживают стилизацию. Как уже сказали ниже, есть масса всевозможных тем (а точнее, скинов). В том числе и выглядящих нативно. Например, как темная тама Win10/11.
Классическое Win32 приложение на Delphi + VCL
Скины это старомодно. Вот стили и темы другое дело.
На делфи наверное сильно неудобно менять облик элементов вплоть до грязных знаков с изменением приватных полей на каждый чих, а не как на WPF: задал стиль, засунул его в словарь ресурсов и применяешь на элементы, их потомки, составные элементы
В VCL с этим не очень. А вот в FMX с этим легче легкого. И удобнее даже, чем WPF.
Hidden text
Создал стиль (для чего угодно). При чем создал визуально
И применяешь к чему угодно
При этом, в стиле могут быть любые поля и контролы, к которым можно получать доступ для каждого отдельного конечного контрола
Последний скрин - это то, что сделано именно таким способом. Здесь каждый контрол имеет свой стиль (WinUI 3, в данном случае). Создан отдельно мной. Всё исключительно штатными средствами.
не в С++, но в паскале был вроде опенсорсный Lazarus, но это ближе к Delphi
C++ Builder просто замечательный и удобный. Главный минус это в том что писать на нём будешь сам и только для себя.
Скажи честно, долго ли мидлу или выше уровнем программисту, без практики с продуктами borland, разобраться в проекте с++ builder, ничем не отличается от любого другого проекта на c++, и идеологии visyvig построения интерфейсов.
Hidden text
Я бы вот с майкрософтовским wpf по остерегся иметь дело, но это наверное личная неприязнь из прошлого а не обоснованные претензии.
Есть, и почему-то про С++ билдер (сейчас он иначе называется) все забывают
А как по мне, идеальный вариант по быстрому сделать Gui, если только под винду
Было бы интересно посмотреть, что было бы при использовании RAD Studio — они вроде активно рекламируют кросс-платформернность, гибкий UI и мелкий размер
Вот статья где реализован симулятор файловой системы на C++ в RAD Studio. Весит 3 мегабайта. Сама файловая система не больше десятка килобайт занимает.
Но меньше там не получить, потому что RAD тянет с собой огромный кусок библиотеки VCL с ресурсами если нужен единственный .exe
Кросс платформенные компоненты GUI (т.н. Fire Monkey) до сих пор какие-то странные/сырые, хотя появились лет 10 назад. Доверять в Delphi можно только старым компонентам VCL , но этот фреймворк не кроссплатформенный, он только под Windows
Не соглашусь. Они странные (т.е. их нужно понять). Они далеко уже не сырые и прекрасно справляются со своей задачей. Множество проектов на FMX уже несколько лет в проде прекрасно себя чувствуют.
И что, правда нет проблем с отображением простейших компонентов? В начале FireMonkey постоянно было то шрифт кривой в ComboBox, то тут что-то съехало, то тут криво отрисовывается , и бороться со всей этой фигнёй дополнительно проверяя, на какой из платформ оно поехало, нет никакого желания. Плюс пусть сначала сделают нормальную компиляцию GUI под Линукс, без всяких дополнительных костылей в виде FMXLinux
Вот пример кроссплатформенного проекта на delphi (и нет, это не html)
https://github.com/HemulGM/ChatGPT
стилизовать нативные элементы управления (controls) Win32 крайне сложно. Мне пришлось бы писать собственную функцию Paint для каждого элемента управления, что потребовало бы столько времени, что я бы успел ещё и обзавестись семьёй.
В прошлой жизни, мне надо было перенести код с чего-то типа Borland C++ Builder на чистую студию, сохранив 5-6 кастомных "красивых" окошек. С одной стороны, там были только кнопки, рисунки, чекбоксы и эдиты, с другой - весь перенос занял у меня месяца два с полной поддержкой всяких радостей типа разных цветов для активной-неактивной-нажатой кнопки. Так что переписывание обработчиков WM_PAINT не настолько страшное, как представляется.
У автора вопрос не в том, чтобы раз перенести, а чтобы в будущем на этом быстро делать приложения.
В вашем подходе, насколько сложно добавить новую кнопку нужного цвета? Снова придётся переопределять WM_PAINT? Портируемое приложение устоялось и меняться не будет. А новое - раскрашивал кнопку полдня, потом кнопка не пригодилась - работа впустую.
Вроде есть полуавтоматизированное перекрашивание нативных win32 контролов:
https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/apply-windows-themes
Соглашусь, что мы с автором решали разные задачи, но это не умаляет того, что сложность процесса все же переоценена.
Эм... Изначально поставили цель писать на C++. Ладно б вы ещё шарп посоветовали, но, если человек пишет на плюсах, значит 99% вероятность, что с питоном его задача не совместима априори
А как тогда с rust? У него есть неплохой крейт tauri и windows-rs. Я с электрона на него пересел. Правда насчет портативности не в курсе - использую nsis установщик.
Но выходной размер - мое почтение.
Но выходной размер - мое почтение
Я думал, в хорошем смысле )))
А тут html/js/react, значит, надо в себя включать браузер.
Тогда уж Nuitka лучше, а то получишь кучу ненужных библиотек
Win32/ImgUI/wxWidgets/Qt в одном сравнении ? Ну такое.
Мы сравнили: нож, газонокосилку, набор отверток и роботизированный завод по производству роботизированных заводов... и оказалось что консервной банки достаточно для забивания двух гвоздей в домашних условиях.
Ну правда, ImGui и виджеты?
Win32 и Qt ?
Автор это очень очень разные штуки, если они у вас в одном сравнении вы вообще не понимаете что вам нужно.
ImGui это круто, но там совершенно непривычная модель рендеринга, когда вы каждый фрейм говорите системе что именно рисовать, совершенно противополжная всем другим моделям, где вы создаете объекты и они там как-то существуют.
WxWidgets это полный простите пиздец, единственная ( сомнительная ) ценность которого это нативные контролы операционной системы. Впрочем может он за прошедшие 10 лет возмужал, но по моим воспоминаниям пользоваться этим нерабочим поделием было невозможно.
Win32 - да можно, но это боль и бессмысленно низкий уровень. Если конечнь цель экономить кило/мегайбайты, чисто по фану то да, иначе просто бессмысленно.
Qt - серьезный продукт на котором можно запилить как мини прогу так и большое тяжело приложение с чем угодно.
(остальные решения щупать не доводилось ).
ImGui самая обычная модель отрисовки и обработки событий, если вы посмотрите из какой области пришел сам фреймфорк. Это самый простой цикл обработки сообщений в играх и графических приложениях.
Да я понимаю, но согласитесь сранивать ImGui с Qt это.. ну я не знаю даже... они разные настолько что области их применения почти не пересекаются. И там и там можно сделать кнопки но с совершенно разной сложностью и целями.
ImGui крут когда у нас есть наш движок и нужно в него добавить пару кнопок, берем и делем. А Qt это же целый мир, если уже брать Qt то придется все на нем делать там соверешнно другая модель разработки и сложность собственно решений. Да и добавить Qt в уже существующий проект это ппц как дорого, а вот докинуть пару файлов imgui должно быть в разы проще. Короче я не понимаю зачем эти вещи в одном списке.
Это да, хочется и красиво и код не писать. Автор похоже просто мечется в море ui фреймворков, не зная к какому берегу примкнуть. Из того что мне довелось пробовать можно добавить еще boden, cegui, elements, foxui, gltk, gacui, nana, mygui, nanogui, rml, xtd. И все небольшие, все можно скомпилить в пару сотен кб
Возможно ImGui не так удобен если нужна стилизация. Нет разделения на форму и код. Нет встроенной поддержки системных тем.
Но функционально на нем можно сделать наверное все, что может понадобиться в относительно нормальном интерфейсе. А с дополнениями вроде ImPlot вообще мощнейший инструмент с минимальными затратами на освоение.
Мне искренне интересно, что по-вашему может Qt, что не получится сделать с Dear ImGui?
Например, удобную работу юзера с таблицами, взаимодействием с ОС, четкая отрисовка шрифтов, работа с окнами, привычный вид элементов интерфейса, оптимизация отрисовки (частичная, а не всегда всю сцену). Работа с текстом и многое, многое другое, что всплывает при разработке
согласен только касаемо "привычный вид элементов интерфейса" и то это спорный аргумент, благодаря засилию веб технологий для отрисовки гуи сейчас иметь нативный вид элементов вообще не в тренде, можно открыть 10 своих самых "любимых" приложений и не увидеть там ни одного нативного элемента.
а по поводу всего остального, чего из перечисленного нет тут, тут или тут
QT для коммерческой разработки надо покупать лицензию, в этом самый главный недостаток. А так он конечно очень хорош, ещё и IDE есть. Это не WxWidgets в Vscode прикручивать. 😁
Требование чтобы все было в одном файле, и ни в коем случае не было DLL -- выглядит как произвольное и не имеющее практической ценности. Если бы автор не выдумывал себе ограничений, то легко бы воспользовался например описанным им вариантом с WPF.
Я далёк от программирования окошек, просто интересно, виндовый anydesk на чем написан?
Electron, Chromium based
Кто вам такое вообще сказал?
Визуально напоминает. Это не так?
Не так
Да, вы правы, не Electron. Решил покопаться и выяснить: оказалось, тема крайней странная:
Основной exe - это загрузчик. Он расшифровывает из себя зашифрованный LZMA-архив, распаковывает его, и там внутри находится другой exe файл, полноценный, но с какими-то хаками в самом exe, чтобы его нельзя было просто запустить.
Что насчёт бесплатной C++ Builder 11 Community Edition?
Лицензия Community Edition применяется только в том случае, если совокупный годовой доход или иные поступления денежных средств Лицензиата (коммерческой организации, государственной организации или индивидуального разработчика) или любые пожертвования (некоммерческой организации) не превышает 5000.00 долларов США (или эквивалент в других валютах) ("Пороговый уровень"). Если Лицензиат является индивидуальным разработчиком, доход от всех подрядных работ, выполненных разработчиком за один календарный год, не может превышать Пороговый уровень (независимо от того, используется ли Community Edition для всех проектов или нет). Например, разработчик, который получает оплату в размере $5000.00 для одного проекта (или более $5000.00 для нескольких проектов), даже если такая работа над проектами не предполагает использования Community Edition, не может использовать Community Edition.
это выдержка из лицензионного соглашения
подобные ограничения буквально подойдут только не работающим студентам, ведь любой! твой доход запрещает тебе пользоваться этой средой разработки бесплатно
Есть еще WTL https://wtl.sourceforge.io/ для чего то простого само то, программа будет маленькая и без каких либо зависимостей.
Всё гораздо интереснее, когда нужно выбрать кросс платформенный ui C++ фреймворк. Вот в этой ситуации и познаётся безысходность.
Если нет конкретной привязки к языку программирования то C# (SharpDevelop) очень хороший редактор с приличным набором компонентов. Я в SharpDevelop обычно всякие гуяшные приложения и пишу.
SharpDevelop же уже 10 лет как мертв?
это предок monodevelop, кстати который майкрософт выкупила и убила как конкурента vs
Тут либо шашечки - либо ехать.)) Бейсик и паскаль тоже можно назвать мертвыми языками но на них до сих пор пишут приложения и игры. По мне так если не для чего то большого и серьезного SharpDevelop вообще идеальная среда разработки после дельфи и борланд с.
WinUI это и правда былинный отказ, каждая версия SDK требует собственный рантайм, который при этом друг с другом даже в пределах патч-версий не дружит (про ошибку "There was no match for the specified key in the index" можно поэмы слагать.
А можно сделать иначе. Тут уже в статье упоминается Delphi и фреймворк FireMonkey. Так вот что можно получить, при этом не имея зависимостей от дотнета и его SDK
Hidden text
Работать будет и на Линуксе и на Маке (правда, конечно же, без AcrylicBlur эффектов у окон)
Про WIN32 API. Зачем для каждого элемента писать свой обработчик wm_paint, не понял? Если элемент нестандартный, можно использовать static стиль и рисовать в нём всё, что заблагорассудится, обрабатывая в едином стиле в одном wm_paint. К тому же, если нужен фон, то тут скорее WM_ERASEBKGND нужен. Вообще, мне опыт показал, что медлительность в разработке рождается от отсутствия сноровки. А когда сноровка есть, можно и на API и на любимом фреймворке написать с одинаковой эффективностью. Всё равно ни одного этапа разработки миновать не удастся.
Согласен. Лет двадцать назад, писал свой фреймворк для полнодесктопных приложений полностью перекрывающих экран в винде. Писалось на чистом WinAPI и GUI+ (ещё 1 версии). Все контролы писались с нуля, так как я сделал свою поддержку скинов (популярная тогда тема) и в принципе, когда хорошо прописываешь архитектуру на нижнем уровне (а я подсел тогда на новые тогда идеи банды 4 с их системой паттернов программирования ), то масштабировать код от простой кнопки на другие контролы не так и сложно оказалось.
Жаль только, потом увлёкся другими идеями, а то в принципе можно было бы в нормальное что то вывести. А так да, сам порой сталкиваюсь со схожими как у автора целями, и в итоге кроме Qt, ничего внятного то и нет, увы.
Упакованные приложения WinUI3 прекрасно работают с WinAPI. Скорее, проблема в том, что Microsoft постоянно бросается от одного проекта к другому, в итоге имеем кучу разных платформ с плюсами и минусами в каждой.
Когда то давно давно, когда msvc только вышагивали как замена win32 gui, я пытался (к сожалению показать нечего, весь мой код с того времени потерян) разработать кодогенератор для win32 gui, который буквально брал на себя весь неудобный и муторный код, делая разработку именно интерфейса простым мышевозекательным (смутно помню я еще в качестве текстового редактора кода использовал far commander с кучей плагинов, заточенных именно на c++ разработку), а позже появился .net c# и winforms (тоже генератор кода но уже в своей экосистеме, и даже пофиг было что это медленно работало) и в этом отпала необходимость... очень странно что майкрософт буквально угробила эту замечательную технологию, заменив ее wpf а потом и ее испортило (разработка из интерфейса на столько нестабильна, что даже странно)
Никогда не понимал потребности разработчиков в темах и смене внешнего вида приложений, за исключение того что предлагает ОС (те же linux kde/gtk), меняя расцветку и форму контролов единообразно. Любые попытки уйти от централизации выглядят неадекватно и криво в результате.
Именно из-за этого маразма, я могу встретить в одной установке xfce приложения с кардинально разным порядком размещения save/do not save/cancel, с разным способом отображения выбранной кнопки (в т.ч. без), т.е. речь идет даже не про темы, а про базовые правила разработки приложений. Когда приложения от ubuntu теперь имеют свой механизм оформления, отказываются принимать классическое поведение окон (например перенос средней кнопкой мыши за край окна) и прочие мелочи, которые определяют комфорт работы.
очень странно что майкрософт буквально угробила эту замечательную технологию, заменив ее wpf
Я считаю, что это случилось, когда .NET стал активно идти в кросс-платформу, а WinForm был жёстко привязан к функциональности user32.dll
В Mono пытались же сделать кроссплатформенную WinForms и у них вроде даже что-то получалось, но потом их купили Microsoft и закрыли тему. Сам правда не пробовал.
Вообще от Microsoft до сих пор нет ни одного кроссплатформенного фреймворка для интерфейса, даже MAUI Linux не поддерживает. В итоге свои же продукты вроде Visual Studio Code пишут на Electron.
Эх, кое-где до сих пор еще работают мои древние приложения на WinForms и пользователи до сих пор довольны...
То, что WinForms (было) прибито гвоздями к форточке это полбеды. Вторые полбеды это то, что оно прибито гвоздями к дотнет, то есть - managed runtime, то есть - невозможность использования без мусорников и прочей лабуды, жрущей ресурсы в фоне.
Разработка интерфейса для Windows — это боль
Если смотреть на проблему в целом, то да, идеальных вариантов нет. Все существующие фреймворки для С++ хороши для своих собственных ниш.
Здесь, вроде бы, еще не упомянут Win32++ - аналог MFC, в исходных кодах ( https://sourceforge.net/projects/win32-framework/ ). Кстати, кажется, и сам M$ выложил уже в открытый доступ исходники MFC. Раньше это могло быть интересным, сейчас уже нет.
Лично я попробовал разные варианты, но, в итоге, вернулся к WTL. Для моих целей, вроде написания обучающих программ, это самое то. Смотрите, для примера, скриншоты моей программы:
http://scholium.webservis.ru/Pics/Lecole.png
http://scholium.webservis.ru/Pics/Lecole2.png
Скажем, чем мне нравится WTL, так это то, что можно легко уйти от стандартов использования оконных компонент, которые, в данном случае, усложняют разработку. Конкретно, в этой программе –три перегружаемых вида (режима работы), которые формируются с помощью одного класса, где только один цикл сообщений, хотя, с виду, там присутствуют разные компоненты, вроде, редактора ячеек. Его мы просто эмулируем. Да и ввод, допустим, любых спецсимволов, для любых алфавитов, тоже реализуется на раз-два.
Короче говоря, пользовательский интерфейс под Виндоуз, для небольших программ, лучше всего, как показывает опыт, делать на WTL.
Возможно я вас не понял, поправьте, если так. Но на скриншотах я не увидел ничего, что нельзя достаточно быстро сделать с помощью чистого win32 api. С Unicode win32 тоже отлично дружит, так что со спецсимволами тоже проблем нет.
По моему скромному опыту, фреймворки одну проблему решают, а две создают. Плакать хочется, когда на форумах mfc ищут решение проблемы, которая на win32 API даже бы и не появилась.
Но на скриншотах я не увидел ничего, что нельзя достаточно быстро сделать с помощью чистого win32 api.
Дело в том, что с WinApi я уже имел дело. До этого сильно увлекался WTL, но что-то там пошло не так, например, нельзя было создать родное меню в дочерних окнах, эмулировать собственный MDI, были сложности с прозрачностью элементов управления, типа CEdit и CRichEditCtrl, неудобная работа с диалогами, возникали даже трудности с закрытием дочерних окон, перехватами сообщений, собклассингом и много чем еще. Поэтому решил перейти на чистый WinApi. Перешел, наваял даже пару проектов, например, редактор ячеек http://scholium.webservis.ru/Pics/CellsEdit.png .
Однако, скажем, просто реализовать сплитер на WinApi - проблема еще та. Да, можно, есть прототип, но не понравились сложности реализации. И таких "мелочей" было масса. Хотя на WTL это реализуется с пол-пинка (см. скриншоты http://scholium.webservis.ru/Pics/LeLysRouge.png и http://scholium.webservis.ru/Pics/LeLysRouge2.png ). А когда я начал делать программу "МедиаТекст" (для ручного, но удобного извлечения текста из медиа-контента (видео, аудио, изображения), (см. http://scholium.webservis.ru/Pics/MediaText.png ), то не выдержал и снова вернулся на WTL. Это была уже моя вторая любовь к нему. Поэтому, говорить и считать можно что угодно, но против собственного опыта не попрешь. Да и не ограничивает WTL WinAPI совершенно.
Qt не так уж и плох, если его уметь правильно готовить. Если использовать какую-нибудь не очень новую версию (скажем, 5.12) и грамотно обработать зависимости (через windeployqt), то результирующая сборка программы может уместиться в 40 мегабайт. Да, там будут dll, а не один exe, но в этом значимой проблемы я не вижу.
40 мегабайт после "обработки зависимости", да еще и с "не очень новой версией" - это не просто ужас, а ужас-ужас-ужас.
Как в этом Qt вообще зависимости выстроены, что оно не в состоянии тащить в бинарник только реально необходимый код? Для простого UI может быть достаточно нескольких десятков килобайт. Даже если накинуть на порядок с учетом нынешних тенденций к развесистому коду - это несколько сотен, но по-прежнему килобайт. Откуда берутся эти десятки мегабайт, да хоть и единицы? Что они там делают, какая часть из них реально используется, а какая бессмысленно висит в зависимостях?
Qt идёт в разделяемых библиотеках, в которых куча функционала - окна, виджеты, кастомизация, абстракции над файловой системой и т. д. Потому то там столько мегабайт. Да, можно ненужные разделяемые библиотеки не брать, но даже нужные весят порядочно. Чтобы прямо всё ненужное убрать, нужна статичная компоновка, что работает или для свободного ПО, или для несвободного по условиям недешёвой лицензии.
Там разве технически можно убрать все ненужное? Сколько я ни встречал высказываний Qt-гуру, работающих с ним по многу лет, меньше 5-6 мегабайт получить не смог никто. А это уже оверхэд на пару порядков минимум.
Ну да, часть кода выкинуть не получится - даже приложение с одной кнопкой будет тянуть код парочки виджетов, работу со стилизацией, цикл сообщений, поддержку юникода и прочее.
Но если у вас на счету считанные мегабайты - Qt не для вас. Он предназначен для случаев, где требования к размеру дистрибутива не столь жёсткие.
даже приложение с одной кнопкой будет тянуть код парочки виджетов,
работу со стилизацией, цикл сообщений, поддержку юникода и прочее
Даже если динамически линковать, требуя рантайм в системе?
Нет, конечно - тогда все ненужное будет в динамической библиотеке.
Но, насколько я знаю, реально грамотную организацию набора действительно необходимых динамических библиотек не осилили ни в одной системе, и большинство приложений по-прежнем тащит с собой одно и то же.
Последствия ООП с развитым наследованием и огромной кучи виртуальных методов. Компилятор банально не знает что будет использовано, а что из них можно выкинуть. Только если ручками наставить уйму дефайнов условной компиляции на каждый возможный метод\класс.
Скорее последствия того, что фреймворк реализован именно на динамических библиотеках и заголовках для них, т.е. нет доступа к исходному коду.
В Delphi, например, тот же VCL или FMX тоже построены на переплетении куч классов и интерфейсов. Но при этом, из-за того, что фреймворк внутри среды разработки представляет собой именно открытый исходный код, то при сборке берется только то, что используется в проекте. И мало того, позволяет даже вносить правки в модули фреймворков для своих проектов
Такие ситуации возникают только при очень корявой структуре наследования. Если вместо десятков-сотен килобайт в бинарник линкуются мегабайты, это значит, что зависимости продуманы откровенно плохо. Возможно, их даже и не пытались толком продумывать, изначально посчитав, что "мегабайт - это же совсем чуть-чуть, даже на терабайтном диске их целый миллион". :)
А потом удивляемся, что ООП ругают, показывая пальцем на такое вот, хотя ООП, как таковое, в этом ни разу не виновато.
Тут вопрос даже не в абсолютном количестве мегабайт, а в соотношении "объем/функциональность кода". Единицы мегабайт - это сотни тысяч строк кода на C++.
Для сравнения: четыре мегабайта кода/данных - это базовый дистрибутив операционной системы OpenWRT, включающий собственно линуксовое ядро со всеми причиндалами, сетевой стек, разумный набор системных служб (которые демоны), набор системных утилит, включая bash, grep, sed, awk, sort, gzip/bzip, tar, vi, opkg, ssh и подобное, типовые команды управления службами, web-сервер с достаточно удобным UI. Неужто функциональность всего этого не превышает функциональности GUI с одной кнопкой?
Думаю, что в Qt попросту никто никогда не думал об оптимизации объема, пока он не становится вопиющим. :)
На сколько я вник в устройство qt могу предположить что его надо не с gui фреймворками сравнивать а с игровыми движками - например бинарник "игры" на юнити будет весить пару метров даже если там одна картинка просто будет на весь экран. Потому что юнити поднимает тяжёлый бэкенд чтобы рисовать крутую графику не зависимо от того что по факту сделал юзер. С qt так же - чтобы нарисовать маленькую кнопочку он поднимет бэкенд рендеринга на вулкане, цикл приложения, систему сообщений и не бог весть что ещё что нужно для полноценного приложения и тянет множество зависимостей для своей работы и не важно что юзер только кнопочку нарисовал.
Как и любой графический фреймворк. Причем, нативные фреймворки тяжелее для подъёма.
В юнити много ресурсов внутри программы. Вдобавок, твоя картинка jpg с размером в 500кб превращается в 32бит текстуру и уже весит 3-6 мб. Это не в защиту именно Юнити, а к тому, что у qt проблема все же именно с библиотеками, которые не делятся при компановке.
По сути верно, но вряд ли там и в движке мегабайты принципиально неразделимого кода. Скорее всего разработчики, как уже говорилось, оценивают объем по отношению не к реально потребной функциональности, а к объему, доступному для хранения/передачи, и обращают на это внимание не раньше, чем приложение/библиотека сами по себе станут занимать достаточно большой объем, медленно скачиваться/загружаться, долго сканироваться антивирусами и т.п.
Хы, кажется я смогу wpf приложение запихнуть в такой размер. Даже с учётом рантайма
Автору рано или поздно придётся запаковывать своё приложение в инсталлер. Appx в тексте обсуждается, но не подошёл. Ну значит MSI. И становится совершенно неважно из какого количества файлов состоит приложение.
Результатом должен быть единый файл
.exeразмером меньше 40 МБ без или с минимальным количеством зависимостей
Мда, 40Мб для Win-приложения уже стало небольшим размером. Я когда-то выбрал себе Delphi+KOL для единого .exe без доп-библиотек .Только требования к размеру кода были в десятки килобайт, а не десятки мегабайт.
Когда-то авно я написал первое реально используемое на предприятии приложение на C# WinForms и народ шутил что это больше на фирус похоже - весит те же десятки килобайт одним файлом. Там конечно фреймворк в системе был установлен.
.NET фрейморк - это уже не-то. Раньше .net в составе Windows по умолчанию не шел.
.net 3.5 версии (именно с нее это стало адекватно по функционалу) шла в поставке начиная с win7, а 4.6 версия идет с win10 (автоматом апдейтится кажется до 4.8)
p.s. win xp шла в поставке с .net версии 2 но это было ниочем (как я понял для silverlight технологии ее тягали)
А с Win 11 какая версия .NET идёт по умолчанию?
Так же 4.8.
С 5-ой версии .net. sdk стал opensource лицензии mit, но почему то не добавляется в поставку с ос
А в чём прикол? Почему не последняя 8-я версия?
Потому что версии .net пекутся как горячие пирожки, и приложениям сейчас удобнее тащить весь фреймворк с собой (точнее не весь, а DLL-ки, которые нужны приложению).
Потому что по факту .Net фреймворка два и они разные. Есть классический .Net с последней версией 4.8, он закрытый, работает только под Windows и уже очень давно не развивается, хотя поддерживается и получает исправления уязвимостей (а внутри еще есть отдельно 3.5 и 4.х, причем ветка 3.5 до сих пор получает обновления безопасности).
И есть кроссплатформенная, открытая, полностью переписанная версия, которая одно время называлась .Net Core, развивалась параллельно и имела свою нумерацию вплоть до версии 3. Когда она дошла до совпадающей с классической цифры 4, достигла определенной зрелости, и уже стало ясно что классическая развиваться не будет ее перестали считать отдельной и назвали общей версией 5.
Версии конечно во многом совместимые, но с массой нюансов. Например у Entity Framework и ASP .Net есть разные версии под старый и новый .Net (с приставкой Core). WinForms и WPF очень долго работали только под старым, потом портировали на новый, но без кроссплатформенности, работают только под Windows. WCF так на новый и не перенесли, читал о попытках сообщества сделать это неофициально, не помню чем закончилось. Новые технологии вроде MAUI не будут работать на классическом.
Это было не настолько давно. В то время как раз шел или ставился корпоративными политиками через систему обновления. У меня такое ощущение, что это была еще Windows XP, но уже на излете жизненного цикла.
Так народ уже давно и прочно потерял ощущение адекватности требуемых ресурсов функциональности кода. Понятие "маленькое", "небольшое", "большое" и "огромное" привязываются только к доступному количеству ресурсов. Если процессор выполняет три миллиарда операций в секунду, а объем памяти составляет 64 Гб, то сотни миллионов операций или десятки мегабайт на какие-нибудь примитивные функции - это "совсем немного".
Это как миллиардер в продуктовом супермаркете: даже если цену бутылки молока или батона хлеба поднять в десять-сто раз, для него это по-прежнему будет "очень дешево", безотносительно к себестоимости продукта. Если в течение длительного времени поднять эти цены в тысячу и более раз, он, возможно, и вспомнит, что раньше оно было дешевле, но ему будет лень рассуждать, почему.
Я имхо чую еще проблемы когда на ноутбуке почуят инициализацию directx запустится дискретная карта (пока-пока энергоэффективность) и можно будет вызвать оверлей амд или нвидиа.
Не могу не упомянуть gtk3 или 4 и даже gtkmm (с ООП и для плюсов). Работать мега просто. Есть свой дизайнер GLAD. Не смотря на то, что на линуксе она предустановлена, проблема на винде такая как и вышеперечисленные: размер .dll может доходить до 300мб
VSC, написанный на Электроне, прозрачно намекает на состояние дел в GUI-разработке на Виндовс :D
VSCode написали на Электроне в двух целях:
сделать кросс-платформенное приложение;
сделать IDE для веб-интерфейса для возможности встраивания в Azure DevOps и подобные сервисы.
Если первое теоретически можно было реализовать на Qt, то для встраивания в веб придётся в любом случае использовать веб-технологии. Побочным эффектом стала лёгкая расширяемость, из-за чего VSCode быстро захватила большую долю рынка.
Что случилось с GUI-фреймворками?
https://tonsky.livejournal.com/311960.html
То, что Вы пишете про Win32, на самом деле относится только к GDI и его оконной подсистеме. :) Win32 - это вообще вся исполняющая подсистема, вместе с управлением памятью, процессами, потоками, синхронизацией, сетью, защитой и прочим.
Но при этом, GUI в win32 - это именно user32.dll и gdi32.dll
Все остальные фреймворки, какие бы они не были "нативные", работают поверх этого и обычно их не считают частью win32. Так что, не вижу никакой проблемы называть UI из user32 как Win32 UI.
Фишка в том, что бОльшая часть API и графической, и оконной подсистем унаследована еще с Windows 1.x и 2.x, когда Win32 был только в проекте.
Да, унаследовано, и было бы хорошо кроме одного но - плохая поддержка highres экранов (масштабирования отличного от 100%). Но главное, формально, поддержку масштабирования можно сделать поверх, дополнительным кодом... просто никому неохота этим заниматься, все берут готовый движок, которых 100500 yj все недоделанные то тут то там.
Просто поверх сделать, увы, не так-то просто. В тех же шаблонах диалогов размеры задаются не в точках, а в "единицах диалога" (DLU), отчего позиционирование/выравнивание элементов диалога получается не совсем очевидным уже в визуальном редакторе ресурсов, и элементы, которые в редакторе четко отстоят друг от друга, в реальном диалоге могут слипаться и даже наползать. Особенно этому подвержены текстовые надписи.
А если взять произвольное окно и пропорционально масштабировать размеры/позиции всех элементов, то даже в простых дробных масштабах вроде 150% получается коряво. Кому-то и такое сгодилось бы - лучше иметь на экране несколько не очень красивых окон, для которых действительно нужен масштаб, нежели иметь увеличенными все без исключения. Но разработчики и винды, и стороннего софта понимают, что после выпуска подобного компромиссного решения пойдет вал жалоб типа "вот это красиво, а вот это ужасно, почему так?". Ну и решили, что лучше пусть все будет одинаково ужасным. :)
В 10-й винде можно выбирать между "всё ужасно" и "частично ужасно".
В свойствах ярлыка legacy-приложения закладка Compatibility → Change high DPI settings → "System" vs "System (enhanced)".
Индивидуально-то все равно не настроить. :( Многие приложения вообще не нуждаются в масштабировании на экранах высокого разрешения. Но чтобы нормально видеть те, у которых элементы очень мелкие, приходится масштабировать весь рабочий стол. :(
Почему нет? Это опция на индивидуальном ярлыке (или на exe-файле).
А, ну разный масштаб на разных приложениях действительно, нельзя.
Я именно о разном масштабе. Даже стандартные элементы у некоторых приложений бывают или чрезмерно крупными, или чрезмерно мелкими для конкретного экрана.
Тут проблема в том, что приложениям Windows изначально было разрешено вылезать за пределы песочницы своего окна и считывать/изменять контролы других окон. Если старое приложение не знает про масштабирование, а у каждого окна свой масштаб, приложению невозможно отдавать координаты окон и контролов внутри них, чтобы всё работало как без масштабирования.
Поверх этого работают только GDI фреймворки. GDI это растровая, пиксельная система. Legacy. Другой класс UI в Windows это векторные фреймворки, работающие поверх presentation, которая в свою очередь поверх DirecrX. Там нет проблем с масштабированием.
Прежде чем начать работу с DirectX, нужно создать окно в подсистеме user32. Хоть полноэкранное, хоть без рамок, но окно. И без HWND, хендла окна, DirectX никуда не поедет. А масштабирование это отдельная тема, не касается комментария, на который вы отвечаете.
Кто такой "векторный фреймворк", и чем он отличается от "растрового"?
При работе с GDI для рисования на девайс контексте используется пиксельная адресация (реальные пиксели или тн device-independent pixel) не суть.
В векторном вы оперируете векторами, относительными позициями и трансформациями. И можете вмешиваться в процесс растеризации, например программируя шейдеры.
Да, вот и выросло поколение... :)
Внезапно. Основная часть - с Win 2.x, World Transforms - с NT 3.51.
Вы разницу между пересчётом интов и несколькими вспомогательными функциями 2d типа bitblt в видеокартах VESA и стадиях работы современного графического конвейера предпочитаете не замечать? Насчёт поколений, мне 42.
Я замечаю, как Вы плавно дрейфуете от противопоставления "векторных" UI-фреймворков "растровым", которым якобы исторически присущи проблемы с масштабированием, к "2d" и "bitblt", которые тут вообще не при делах.
Такое впечатление, что между "растровой" и "векторной" графикой Вы видите столь же принципиальное отличие, как между растровым и векторным форматом шрифта или изображения, где такое отличие действительно есть.
А основная графика и в винде, и в любой другой графической системе - именно векторная, проблем с масштабированием у нее нет. Разве что мелочи вроде целочисленных координат, но и это не проблема - достаточно оперировать величинами в десятки-сотни тысяч условных точек, добавив к ним масштаб хоть в виде рациональной дроби, чтобы практическая точность получилась не хуже, чем на чистой плавучке.
"Векторные" фреймворки - это не столько UI, сколько удобное представление всякой визуальной математики. Но и оно не "радикально", а всего лишь "несколько" удобнее того, что уже давно реализовано в виндовой графике.
bitblt и прочие функции GDI со времен царя гороха ускоряются железом графических адаптеров, выбор видеокарты для винды 95 помните? Там кроме большего объёма памяти, который влиял на кол-во цветов была ещё фича ускорение 2д.
Впечатление правильное так и есть.
В винде, да векторная, но старый GDI от этого векторным не стал.
Такое ощущение, что толком Вам сказать нечего, поэтому хватаетесь за все, что хоть как-то имеет отношение к винде и графике.
Именно про винду и графику тема. Что бы понимать о чем я говорю надо знать как эволюционировала графика в Windows хотя бы до появления presentation foundation а не застрять в win32 api, который вообще может отсутствовать на уровне пользовательского приложения (см на различные версии винды для армов)
про wince можно было бы не вспоминать, этот труп уже закопали глубже некуда и вытаскивать его ну не надо.
Это сейчас модно называть CE трупом, когда под ARM таки допилили полноценную NT. А году в 2005-м, куда еще можно было, на особо напрягаясь, перенести почти любое десктопное приложение? CE была этакой Win9x под устройства на ARM/MIPS, и там свою задачу выполнила честно. :)
Я про виндовые планшеты, surface например и прочие. WinRT версия-сборка вроде называлась.
Вы начали с того, что противопоставили "векторные фреймворки", где "нет проблем с масштабированием", "пиксельной" (legacy) виндовой графике. То есть, виндовой графике проблемы с масштабированием якобы присущи лишь потому, что она "пиксельная". Я пытаюсь добиться от Вас описания конкретных проблем с масштабированием, возникающих именно из "пиксельности" графики.
Другой вопрос - зачем Вы уперлись в BitBlt и подобные растровые операции, которые никогда не были базовой частью виндовой графики? На них делаются или эффекты, или ускорение; для отрисовки, как таковой, они не обязательны. И любой "векторный фреймворк", если упрется в потолок производительности, тоже будет предлагать растровые операции для ускорения, ибо деваться-то некуда.
В каких версиях винды для ARM отсутствует Win32 API?
Про масштабирование вы первый раз спросили. Проблем там миллион, начиная от качества отображения, заканчивая не соответствия масштабов различных элементов и текста внутри, кривым лэйаутом. Последнее не из за растров конечно, а из за способностей подхода 30 лет отроду.
В битблт я не упирался, просто как пример привёл. Они всегда были базовой частью, окошки по вашему чем перерисовываются, когда двигаются, накладываются в GDI? Так вот эта операция одна из нескольких, для которых сразу же заюзали аппаратное ускорение. И на этом примерно и закончили.
В отличии от современного подхода, где растеризация это одна из стадий графического конвейера видеокарты. Где вы там ожидаете упирание пользовательского Gui мне неведомо.
WinAPI отсутствовало в WinRT например, ОС которая работает исключительно с приложениями ModernUI или во что его там переименовали.
Про несоответствие масштабов элементов и текста я же первый и сказал, зачем повторять-то? И они действительно никак не связаны с "пиксельностью" - просто изначально не было нужды в автоматическом масштабировании, и потом еще почти тридцать лет ее не было.
И с масштабированием, как таковым, в этой "пиксельной" графике тоже нет никаких проблем - приложения, которые сами создают все элементы в окне, прекрасно масштабируются вдоль и поперек. Проблемы возникают только при формировании элементов управления из ресурсов, к графике это прямого отношения не имеет.
Растровые операции при наложении/перемещении окон тоже не связаны с масштабированием, ибо выполняются над уже отрисованными (в видео- или обычной памяти) участками.
В WinRT, как и во всех остальных версиях, все прекрасно с WinAPI. То, что UWP-приложения не имеют к нему прямого доступа, никак не влияет на его существование и работу. Это примерно как Java VM в андроиде, где базовые API линуксового ядра тоже никуда не делись, и при желании могут быть использованы.
Это вы нормальным называете?
Нет, это всего лишь извращенный способ поиска функций, экспортируемых Win32 DLL, из приложений UWP (Metro-style, Modern и т.п.). Для этих "современных" приложений в винде организована убогая "официальная" среда, заточенная на типовые операции - так они пытаются достичь "безопасности".
Самое смешное в том, что они оформляются в обычный PE/EXE-файл с традиционными зависимостями (kernel32, user32, gdi32, advapi32 и т.п.), и работают в стандартной среде Win32 (которая по-прежнему "корневая"), просто набор доступных API искусственно ограничен стандартными средствами разработки еще на этапе компиляции/сборки.
Забавно, кстати, бывает посмотреть, какие функции они импортируют из user32 и gdi32. :)
Я почти уверен, что, если собирать такое приложение не по стандартной схеме "в студии создали проект, добавили к дефолтному коду свой, нажали кнопку Build, получили пакет APPX", то можно добавить туда статические ссылки на любые DLL. Но большинству разработчиков таких приложений это не под силу.
Те, кто хочет полную функциональность Win32, пишут под WinRT обычные (desktop) приложения. На ряде устройств (том же Surface) их просто так не запустишь, нужно хачить систему. Но, если посмотреть внутренности прошивки, то сразу видно, что предустановленных Metro-приложений там от силы десяток, а все остальное, включая IE и офис - стандартные Win32 - "десктопные", консольные и службы.
А кстати есть ещё Slint: https://slint.dev
Я сам его не юзал, но выглядит интересно и приятно. Если кто-то смотрел его более внимательно или вообще есть опыт его использования, было бы очень интересно послушать мнение.
Есть еще годный Nuklear. Тоже immediate mode, но умеет в самые разные бэкенды (хоть GDI), и при этом микроскопично минималистичный, без зависимостей, header-only, с кучей биндингов и т.д..
Эх... Куда катится мир... Ещё в прошлом тысячелетии сделать нативный интерфейс под Win32 можно было без напряга за 5 минут (ну, хорошо, несколько часов, если реально сложный интерфейс с кучей меню, tool-баром и несколькими окнами). Да, я про Delphi/CBuilder, конечно же. И на выходе получаем приложение без внешних зависимостей, небольшого размера... А сейчас клепают монстров на всяких модных GTK и иже с ним, или вообще тянут в дистрибутив ядро браузера ради отрисовки интерфейса.
А ведь ещё был (ну, формально есть и сейчас) крутейший проект KOL/MCK, который уделывал на голову "голый" VCL в плане размера выходного файла. Там было немного больше заморочек при разработке, конечно.
без внешних зависимостей
в моих ехешниках, из Delphi 7, иногда была зависимость, на некоторых компах требовалось qtintf70.dll подложить. Но может я и не правильно собирал, или сторониий компонент был зависимый.
А сейчас клепают монстров на всяких модных GTK и иже с ним
Причем часто библиотеки фреймворков еще и хранятся локальными копиями для каждого использующего их приложения.
в прошлом тысячелетии сделать нативный интерфейс под Win32 можно было без напряга за 5 минут
А что поменялось? Builder работает - берите и рисуйте.
Он 64-битные приложения умеет собирать?
Умеет. Он умеет и под Mac собирать и под Linux и под iOS и Android
Жаль что сама среда разработки только под win, интересно как отладку linux/mac приложений делать? Есть такой же инструмент который даёт adb для андроид удаленной отладки?
Delphi умеет, а C++ Builder с недавних пор не умеет (на сколько я знаю, осталась только поддержка Windows). Чисто гипотетически, может ли случиться так, что C++ Builder появится как плагин/обёртка над современными версиями Delphi?
Скорее всего появится такая же поддержка. Сейчас, в свежей версии среды D12, даже сборка проекта C++ доступна только под Windows. Полагаю, это связано с переходом на новую версию clang. И в будущих версиях будут добавлять поддержку под другие платформы.
Хорошая новость. Думал перейти на Delphi, но синтаксис не очень нравится. Опять дилемма: оставаться на C++ Builder или всё же выбрать Delphi? Разработка только начата, ещё не поздно "поменять коней".
Привыкнешь. Плюс - меньше выделений памяти, больше самоочистки. Минус - нельзя создать объект на стеке, только в куче. Плюс - много синт. сахара подвезли, если изучить будет интересно.
Плюс - меньше выделений памяти Минус - нельзя создать объект на стеке, только в куче
Противорение, нет?
Да и на стеке создать данные не проблема, нужно пользоваться record (object) вместо class. Собственно, как в C# struct vs class - заранее, при создании класса, опрелеляешь тип аллокации.
Не противоречие. В Делфи больше управляемых типов. Строки, массивы, рекорды.
А record и object <> class. Разные возможности
Насколько я знаю, по политике аллокации, record = object.
В старых Delphi, у record невозможно было создавать методы, и поэтому, чтобы получить какое-то подобие ООП + создавать объекты на стеке, можно было объявить их как object.
Не противоречие. В Делфи больше управляемых типов
Похоже, я вас неверно понял. Под "меньше выделений памяти" вы имеете ввиду не фактическую нагрузку на кучу, а количество ручных телодвижений.
вы имеете ввиду не фактическую нагрузку на кучу, а количество ручных телодвижений
Да, так и есть.
Да, object на стеке, но к сожалению, он уже давно deprecated. Так что его лучше вообще не брать в расчет. По этому, в Делфи отсутствие создания class на стеке - недостаток. Многим этого не хватает для производительного кода. Да и внутри фреймворков этого не хватает. Представьте, что есть в фреймворке код отрисовки, в котором создаётся class для работы и после вычислений очищается. Это сильно сказывается на производительности.
Для этого и надо использовать record. Благо, довольно давно в record можно создавать методы, и по удобству использования он не хуже class. Отсутствующие возможности - конструкторы, деструкторы, наследование, виртуальные методы. Явно всё не то, что нужно для критических по производительности кусков кода.
А почему, собственно, боль именно под Windows? Под другими ОС прямо все в шоколаде?
Простите, но мне кажется заголовок не соответствует статье. Потому что в заголовке например упоминается Windows (а что на линукс или макось делать UI в одну либку типо раз два?). Да и Вы сами перечислили кучу библиотек и технологий которыми это можно сделать, но проблема же не в них а в требованиях к задаче.
Реализация Motif выпущеная в 2012 под LGPL представляет из себя стандарт и реализацию как я понимаю для всех операционных систем в том числе и Widnows. В чем проблема использовать именно её?
Разработка интерфейса для Windows — это боль