Здравствуйте, bnk, Вы писали:

bnk>Такое IMHO может сделать только сама Microsoft. Зачем кому-то еще такое делать.

Не понял. Это мог бы делать кто угодно. Оформить несколько независимых элементов в отдельную DLL, оформить ее в виде сборки SxS, чтоб можно было разделять между приложениями, и вперед. Глядишь, через несколько лет MS бы это выкупила и включила в стандартную поставку винды.

bnk>Это же не будет ни интелисенса нормального

Что такое "нормальный интелисенс", и почему его не будет? IntelliSense работает по объявлениям-заголовкам, которые доступны для любого стороннего расширения. Как, по-Вашему, он работает для тех же ATL, WTL, Qt и прочих?

bnk>ни поддержки фреймворков

Если фремворки всегда поддерживали стандартные виндовые элементы, которые добавлялись в новых версиях винды — почему бы им не поддерживать и сторонних, буде они станут мало-мальски популярными? Проблема, на мой взгляд, в том, что сторонние разработки UI четко делятся на два класса: убогие и глючные — для себя, и избыточно-навороченные — для распространения/продажи. А умеренно-простых, "ортогональных", легко встраиваемых в код с любой парадигмой — почти нет.

bnk>Я когда под винду писал, такие вещи на чем-то типа codeproject искались. Вот например PropertyGrid на чистом WinAPI

Спасибо, погляжу его. Может, и подойдет.

bnk>Не рассматривал вариант перейти на HTML? Плюс несколько мегабайт

Рассматривал, но прежде всего останавливают "плюс несколько мегабайт" (которые, как обычно, тупо копируются, никак не разделяясь между разными приложениями), и сверхзадача "управлять размещением непременно через CSS". Мне гораздо больше понравилось бы управление размещением через вызов методов и/или задание двоичных таблиц, которые на более высоком уровне могли бы быть обернуты в CSS.

Здравствуйте, Videoman, Вы писали:

V>Странно считать что разделение связанной логики по разным функция что-то там "размазывает".

Оно размазывает внимание при работе с текстом. Код, который в компактном написании весь оказывается в пределах страницы, при написании в виде набора функций разносится на несколько страниц.

V>Сейчас в программировании это наоборот тренд: все становится функциональным. Кругом маленькие "чистые" функции на каждый чих.

Когда тренд приводит к бездумному применению идеи, ничего хорошего в этом нет. Когда фрагмент кода выполняет независимую логическую задачу, которой легко дать осмысленное имя — его, безусловно, имеет смысл выделять в функцию. Но есть множество фрагментов, общих для кода с условным переключением, которым трудно дать осмысленное и понятное имя, и тогда получаются функции вроде prepare_values_for_processing. Чтобы вспомнить, какие именно values там prepare, нужно туда лезть и читать.

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

Вздор. Чтобы менять стиль поведения того же Report View в достаточно широких пределах, вовсе не обязательно сабклассить функцию окна — достаточно задать стили при создании элемента, или послать управляющие сообщения после этого, или обрабатывать сообщения, посылаемые им родителю.

V>Ну класс окна определяет чем его поведение отличается от стандартного. Просто делаешь Attach к хендлу нужного окна. Сама процедура окна, на сколько я помню, сабкласится, но тутже вызывает старую, и ты спокойно можешь переопределять только то что нужно.

Да это элементарно, нет смысла об этом говорить. Но, если элемент не настраивается гибко извне, то единственным способом изменить его поведение будет почти полное переписывание его кода у себя. Тогда уж проще сразу сделать с нуля, чтобы не заморачиваться взаимодействием.

Здравствуйте, Евгений Музыченко, Вы писали:

У>>А какая связь между MessageLoop и твоим контролом? И какая разница, кто, где, и как реализован?

ЕМ>Бывает полезно обрабатывать некоторые сообщения непосредственно в главном цикле их выборки, до вызова оконных процедур. Но в WTL, насколько я помню, как раз можно их перехватывать.

Ну только главный цикл и оконная процедура всё равно никак не связаны. WTL тебе главный цикл свой не навязывает, но при необходимости, упрощает его. Хотя там и так обычно всё просто


ЕМ>Хм, я считал, что в WTL оно табличное, как и в MFC. В последовательность if'ов влезть гораздо проще, чем в таблицу.

А посмотреть не судьба? Там обычно у обработчиков есть OUT BOOL параметр handled, т.е. ты можешь как-то обработать сообщение, но не сказать, что оно handled, и оно дальше пойдёт обрабатываться.

WTL — очень легкая обертка над WinAPI, но, тем не менее, писать на ней гораздо приятнее. Её и написали те, кому не нравился MFC, но на WinAPI уже сил не было писать

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>У меня самые тяжелые EXE — 120-150 кило байт x86, 170-200 — x64. Для них даже 5-10 мегабайт чистого UI — это очень много, а 20 — неимоверно, чудовищно много.
Тебе эти мегабайти как-то спать мешают? Или влияют на продажи?

ЕМ>Вопрос ведь даже не в том, что они тяжелые сами по себе. Хранилища нынче большие, каналы широкие, и те 20-25 Мб даже на дохлом ADSL в 5 Мбит/с скачиваются за полминуты. Реально меня вымораживает то, насколько это все избыточно.
Ну так это проблемы винды, в линухе чаще всего свои либы тащить не надо.

ЕМ>С одной стороны нам трудолюбиво втирают, что нужно повышать повторную используемость кода, использовать компактные конструкции вместо развесистых, а с другой — столь же трудолюбиво клепают софт, избыточный на тысячи и более процентов, и подают его так, будто это нормально.
Ой как все запущенно... Ты знаешь, что сейчас простейшие однастраничные сайты может быть под сотню мегабайт? То, что ты съэкономишь расчесав свои нервы и потратив время это примерно 0.0000000000000000000000000000000001% от трафика таких страниц.

ЕМ>Когда на Qt делают масштабный продукт вроде VirtualBox, который по определению не может быть компактным — это вполне оправдано (хотя в итоге VBox, при функциональности, сравнимой с VMware Workstation, минимум вдвое компактнее). А когда объем кода UI, из которого больше половины никогда не используется, в несколько раз превышает объем кода логики приложения — это явный идиотизм.
Почему?

ЕМ>Когда же в систему ставится множество приложений, каждое из которых тащит с собой собственные копии одного и того же кода UI — это идиотизм в квадрате.
В линухе в общем случае это не так. Но особо популярные приложения всеже тащат свои либы чтобы уменьшить вероятность проблем на стороне пользователя.

S>>Специальная сборка не нужна. qtwindeployqt устанавливает только то, что нужно.
ЕМ>И какой объем UI-кода он мне установит для добавления в приложения только базовой функциональности UI, без локализации, цветовых градиентов, анимации и прочих чисто эстетических плюшек?
Раньше (Qt 5.1-3) было ~5 метров. Сейчас такое не пробовал, у меня сейчас инсталятор простого приложения примерно 30 метров, логики там килобайт на 20.

ЕМ>Так в этих случаях получается перевес объема кода UI над логикой в несколько раз минимум.
Да и пофиг.

ЕМ>И как я могу выдрать из Qt обработчики его отдельных элементов UI, чтобы вызывать их из своего цикла обработки сообщений, и чтобы они не тянули за собой всю инфраструктуру Qt, предназначенную для организации платформенно-независимой среды? Они же внутри себя, как я понимаю, работают не с WinAPI, а с элементами этой самой среды, которая составляет изрядную часть кода.
Я тебя не понимаю. Ты можешь контролировать цикл обработки сообщений и вызывать кутишный когда тебе удобно (а не наоборот, как оно обычно).
В кутишном слоте, отвечающем за обработку интересующего тебя события, например, нажатие на кнопку, ты как-то уведомляешь свой не-кутишный код и уже в нем делаешь то, что тебе надо.
Условно:
твой код->QEvenLoop::processEvents->QPushButton::onClick->уведомление твоего кода через какие-то элементы синхронизации
Весь контроль и вся логика у тебя.

ЕМ>Это буду смотреть я сам. Понимаю, что большинство юзеров сглотнет и не такое, но изготавливать технически убогий шлак мне претит.
Можно смотреть в сторону статической линковки с оптимизацией. Большая часть не нужного будет выкинута.

utorrent известный своим минимализмом и тот 2 мегабайта. Он закрытый, но можно, наверное, найти инфу как они это делают.

Здравствуйте, Skorodum, Вы писали:

ЕМ>>Вопрос ведь даже не в том, что они тяжелые сами по себе. Хранилища нынче большие, каналы широкие, и те 20-25 Мб даже на дохлом ADSL в 5 Мбит/с скачиваются за полминуты. Реально меня вымораживает то, насколько это все избыточно.
S>Ну так это проблемы винды, в линухе чаще всего свои либы тащить не надо.

с Qt это скорее всего не сработает, придется тащить ту версию, с которой собирал

Здравствуйте, night beast, Вы писали:

NB>с Qt это скорее всего не сработает, придется тащить ту версию, с которой собирал
Так можно собирать с расчетом на целевую платформу. Если в убунту версии x.y стоит Qt 5.9, то с ней и собирать, обратную совместимость Qt гарантирует внутри мажорных версий, так что обновление линухи не проблема.

Здравствуйте, Евгений Музыченко, Вы писали:

V>>Странно считать что разделение связанной логики по разным функция что-то там "размазывает".

ЕМ>Оно размазывает внимание при работе с текстом. Код, который в компактном написании весь оказывается в пределах страницы, при написании в виде набора функций разносится на несколько страниц.

Говнокодер детектед


V>>Сейчас в программировании это наоборот тренд: все становится функциональным. Кругом маленькие "чистые" функции на каждый чих.

ЕМ>Когда тренд приводит к бездумному применению идеи, ничего хорошего в этом нет. Когда фрагмент кода выполняет независимую логическую задачу, которой легко дать осмысленное имя — его, безусловно, имеет смысл выделять в функцию. Но есть множество фрагментов, общих для кода с условным переключением, которым трудно дать осмысленное и понятное имя, и тогда получаются функции вроде prepare_values_for_processing. Чтобы вспомнить, какие именно values там prepare, нужно туда лезть и читать.

Высосал что-то из потолка. Приведи пример, когда switch/case в оконной функции удобнее отдельных обработчиков сообщений


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

ЕМ>Вздор. Чтобы менять стиль поведения того же Report View в достаточно широких пределах, вовсе не обязательно сабклассить функцию окна — достаточно задать стили при создании элемента, или послать управляющие сообщения после этого, или обрабатывать сообщения, посылаемые им родителю.

Извини, но ты говоришь о том, что дефолтное поведение просто достаточно вариабельно у некоторых контролов. Для этого (кто бы мог подумать) действительно не надо ничего сабклассить. Но тебе говорят о другом


ЕМ>Да это элементарно, нет смысла об этом говорить. Но, если элемент не настраивается гибко извне, то единственным способом изменить его поведение будет почти полное переписывание его кода у себя. Тогда уж проще сразу сделать с нуля, чтобы не заморачиваться взаимодействием.

Это не так. Но если нравится писать всё целиком с нуля — наздоровие

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Если фремворки всегда поддерживали стандартные виндовые элементы, которые добавлялись в новых версиях винды — почему бы им не поддерживать и сторонних, буде они станут мало-мальски популярными?

Потому что все виндовые контролы управляются через сообщения. И для старых известных контролов написаны обертки. Никто в здравом уме сейчас с SendMessage не работает. Поэтому, как бы круты твои контролы не были, никто ими пользоваться не будет. Ну, или ты напишешь обёрток для MFC/WTL/WPF/Qt и тд и тп.

Ты как будто спал последние 20 лет и тут проснулся

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Вздор. Чтобы менять стиль поведения того же Report View в достаточно широких пределах, вовсе не обязательно сабклассить функцию окна — достаточно задать стили при создании элемента, или послать управляющие сообщения после этого, или обрабатывать сообщения, посылаемые им родителю.

Так, секундочку. То, что делает из дефолтного окна Report View и есть собственная процедура окна, в которой и обрабатываются все эти управляющие сообщения. Мы же говорим об архитектуре в общем и какое там окно будет у тебя х.з. Потом у WinAPI очень неудобно реализован механизм CSS для бедных, где окно посылает сообщение родительскому что бы понять контекст и применить некоторые стили. Опять же, в ручную это все замучаешься делать. Иногда, например, нужно сделать рефлексию и самому среагировать на своё же сообщение родительскому окну и всякие библиотеки помогают в этом.

ЕМ>Да это элементарно, нет смысла об этом говорить. Но, если элемент не настраивается гибко извне, то единственным способом изменить его поведение будет почти полное переписывание его кода у себя. Тогда уж проще сразу сделать с нуля, чтобы не заморачиваться взаимодействием.

С чего бы это. Вообще-то стандартным подходом всегда было назначение своей процедуры окну и делегирование всех вызовов старой, а в новой остается только твоя новая настройка. Можно конечно все это делать руками, но WTL позволяет тебе это делать оперируя классами С++ и их наследованием друг от друга.

Опиши подробно задачу которую хочешь решить и тогда можно будет уже детально разобраться и понять как проще это сделать и какие проблемы в связи с этим у тебя возникают.

Здравствуйте, Skorodum, Вы писали:

S>Тебе эти мегабайти как-то спать мешают? Или влияют на продажи?

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

А вот самоощущение это совершенно точно испортит. Прежде всего — пониманием того, что я тоже повелся на дурацкую и вредную тенденцию "делать криво просто потому, что можно". Не стоит делать откровенно криво лишь потому, что есть возможность. Это сродни подходу "раз тут все равно грязно, то и я поссу".

S>Ну так это проблемы винды, в линухе чаще всего свои либы тащить не надо.

То есть, в линуксе с более-менее разнообразным набором приложений уже есть разделяемые между этими приложениями .so, или же каждое приложение просто выставляет зависимости, по которым менеджер пакетов тупо выкачивает нужные библиотеки?

S>Ты знаешь, что сейчас простейшие однастраничные сайты может быть под сотню мегабайт?

Знаю. Это тоже криво — их тоже делают лишь потому, что можно. И тестируют, судя по всему, непосредственно в 10-гигабитной локалке с сервером, ни разу не сомневаясь, что у всех клиентов будет хотя бы гигабит.

S>То, что ты съэкономишь расчесав свои нервы и потратив время

Я ж говорю, что дело не в экономии. Мне просто по-человечески неприятно предлагать пользователям продукт, в котором 80-90% мусорного, никогда не используемого кода.

ЕМ>>когда объем кода UI, из которого больше половины никогда не используется, в несколько раз превышает объем кода логики приложения — это явный идиотизм.
S>Почему?

Если Вам предложат ординарный легковой автомобиль, потребляющий 30 л топлива на 100 км пробега — Вы тоже сочтете это нормальным? Даже если топливо будет стоить копейки, остаются еще двуокись углерода и токсичные примеси. Зачем гадить вокруг себя, если можно этого не делать?

S>В линухе в общем случае это не так. Но особо популярные приложения всеже тащат свои либы чтобы уменьшить вероятность проблем на стороне пользователя.

Они их тащат исключительно для себя, или другое подобное приложение тоже сможет использовать установленные экземпляры этих либ?

S>Раньше (Qt 5.1-3) было ~5 метров.

А код Opera 9.5 под Windows Desktop (уже распакованный из дистрибутива) — ~4.5 метра. Полноценный браузер со всем своим GUI, HTML/CSS2 (местами и CSS3), работой с сетью, JavaScript-машиной, почтовиком и прочей требухой. И как после этого воспринимать Qt?

ЕМ>>Так в этих случаях получается перевес объема кода UI над логикой в несколько раз минимум.
S>Да и пофиг.

Когда всем пофиг — это деградация.

S>Ты можешь контролировать цикл обработки сообщений и вызывать кутишный когда тебе удобно (а не наоборот, как оно обычно).

Я хочу не только контролировать поведение, но и исключить присутствие в моих EXE/DLL (а также рядом с ними) заметных объемов кода, заведомо не используемого в моих целях. Такое возможно с Qt при статической линковке? Какие там примерно получаются объемы при использовании только самых простых элементов UI, без украшений?

S>utorrent известный своим минимализмом и тот 2 мегабайта.

У меня 1.8.2 (2009 год). Упакованный в UPX он 250 кб, распакованный — 550. Кстати, его UI мне всегда очень нравился. Потолстев вчетверо (или в восемь раз) к нынешнему времени, он стал в чем-то функциональнее и/или удобнее?

Здравствуйте, удусекшл, Вы писали:

У>Говнокодер детектед

От детектеда слышу.

У>Приведи пример, когда switch/case в оконной функции удобнее отдельных обработчиков сообщений

Например, когда при нажатии/отпускании клавиши или кнопки мыши нужно выполнить похожие действия с одними и теми же объектами. Эти действия по сути комплементарны друг другу, и вполне логично записывать их рядом. Если разносить их по отдельным обработчикам, эта связность перестает быть явной. Разве что делать третью функцию с логическим параметром, и вызывать ее с true для нажатия, с falst — для отпускания. Ну, или называть обработчик OnDownAndUp, и в нем дополнительно ветвиться по коду сообщения.

У>ты говоришь о том, что дефолтное поведение просто достаточно вариабельно у некоторых контролов. Для этого (кто бы мог подумать) действительно не надо ничего сабклассить. Но тебе говорят о другом

Тогда нужно говорить не о "дефолтном" поведении, а о "стандартном", "искаропки" и т.п. Дефолтное — это по умолчанию, без каких-либо явных указаний. Такие явные указания даются стилями или управляющими сообщениями, меняя дефолтное поведение в пределах стандартного. А сабклассинг уже позволяет вывести поведение за рамки стандартного.

У>Никто в здравом уме сейчас с SendMessage не работает.

И пожёстче работают. Муз. программа Reaper, например, использует самодельное подмножество WinAPI, запускающееся на Винде, Маке, Линуксе. Уж не знаю, насколько в здравом уме автор этого подхода, но продукт получается отличный.

А несравненный Blender весь UI отрисовывает сам на OpenGL.

Вопрос Евгению. Если так не нравятся фреймворки, то почему бы сразу не взять какой-нибудь Dear Imgui, и не рисовать интерфейс самому? Подход с затягиванием в свой проект легковесных "безфреймворковых" компонентов тоже чреват. Каждый из них независимый, и будет тянуть собственную обвязку и вспомогалово. Подгребешь пару десятков таких, если найдёшь, и вот тебе уже на ровном месте зоопарк в кодовой базе.

Здравствуйте, Евгений Музыченко, Вы писали:


У>>Приведи пример, когда switch/case в оконной функции удобнее отдельных обработчиков сообщений

ЕМ>Например, когда при нажатии/отпускании клавиши или кнопки мыши нужно выполнить похожие действия с одними и теми же объектами. Эти действия по сути комплементарны друг другу, и вполне логично записывать их рядом. Если разносить их по отдельным обработчикам, эта связность перестает быть явной. Разве что делать третью функцию с логическим параметром, и вызывать ее с true для нажатия, с falst — для отпускания. Ну, или называть обработчик OnDownAndUp, и в нем дополнительно ветвиться по коду сообщения.

Чет мне сейчас лень проверять, но если мне не изменяет склероз, такие события всегда в один обработчик валились, с флажком нажато/отпущено. Ты, походу, вообще смотреть не пробовал, что как сделано, но заранее всё осуждаешь. Прям как с Пастернаком, один в один.



У>>ты говоришь о том, что дефолтное поведение просто достаточно вариабельно у некоторых контролов. Для этого (кто бы мог подумать) действительно не надо ничего сабклассить. Но тебе говорят о другом

ЕМ>Тогда нужно говорить не о "дефолтном" поведении, а о "стандартном", "искаропки" и т.п. Дефолтное — это по умолчанию, без каких-либо явных указаний. Такие явные указания даются стилями или управляющими сообщениями, меняя дефолтное поведение в пределах стандартного. А сабклассинг уже позволяет вывести поведение за рамки стандартного.

И какая разница? Смысл-то ты уловил?

Здравствуйте, serj.e, Вы писали:

У>>Никто в здравом уме сейчас с SendMessage не работает.

SE>И пожёстче работают. Муз. программа Reaper, например, использует самодельное подмножество WinAPI, запускающееся на Винде, Маке, Линуксе. Уж не знаю, насколько в здравом уме автор этого подхода, но продукт получается отличный.

Я же не отрицал, что есть отдельные упоротые товарищи


SE>А несравненный Blender весь UI отрисовывает сам на OpenGL.

Или даже команды.

Ты еще фотошоп вспомни, или ещё что-нибудь, что начинали писать ещё тогда, когда никаких MFC/WTL и, тем более, дотнетов с их WPFами, не было.


SE>Вопрос Евгению. Если так не нравятся фреймворки, то почему бы сразу не взять какой-нибудь Dear Imgui, и не рисовать интерфейс самому? Подход с затягиванием в свой проект легковесных "безфреймворковых" компонентов тоже чреват. Каждый из них независимый, и будет тянуть собственную обвязку и вспомогалово. Подгребешь пару десятков таких, если найдёшь, и вот тебе уже на ровном месте зоопарк в кодовой базе.

Добрый ты человек

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, SaZ, Вы писали:

SaZ>>А вы пример можете привести?
ЕМ>Да хоть нечто подобное таблице параметров, что в правой части диалога настроек MS VS. Где у каждого параметра есть тип, умолчание, возможные варианты значений и т.п.

Там в соседнем треде кинули проперти грид — так в деталях же захлебнуться можно на фоне любого внятного фреймворка. Особенно если что-то надо кастомизировать.
Жду от вас реальный пример контрола с кодом, который будет удовлетворять вашим требованиям.

SaZ>>Делать полностью абстрактные контролы очень тяжело — нужно очень много писать руками, в том числе логику.
ЕМ>Что такое "полностью абстрактные"? Хочется, как в WinAPI, создать такой элемент, последовательными вызовами методов набить его данными, задать какие-то особенности поведения, и активировать, задав при этом объект callback-класса (или просто функцию), через которые он будет сообщать о событиях и просить уточнений.

Так очень много вещей нужно в голове/коде держать. И нормально спроектировать один контрол с минимальными возможностями кастомизации не сильно проще, чем написать свой фреймворк.
Вы писали свои контролы? Я писал свои виджеты под Qt, с поддержкой стилей, кастомизации через QSS и редактора. Тот ещё гемморой получался. А наитивно это делать — ещё сложнее.

SaZ>>Фреймворки как раз призваны упростить разработку контролов. Сравните, к примеру, сложность реализации пользовательской логики для дерева из Qt (QTreeView) и винапишного.
ЕМ>Там разница не в том, что Qt — фреймворк, а в том, что соответствующий элемент Qt уже набит логикой (как нужной мне, так и напрочь не нужной), а винапишный — примитивная заготовка.

А зачем вам использовать сразу всю возможную логику? Используйте только то, что вам нужно
Набить список текста на Qt — пару строк кода. На чистом винапи 20-30.
Сделать древовидный выпадающий список с чекбоксами на Qt — строк 20-30. На чистом винапи вы и в 300 не уложитесь.

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

Опишите исходную решаемую задачу и вашу мотивацию к наитивным контролам, тогда можно будет более предметно разговаривать.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, Михaил, Вы писали:

М>>А вы на голом винапи пишете?

ЕМ>Пока, увы, да. Давно хочу найти что-нибудь несложное/нетяжелое, но легко модифицируемое и расширяемое, но предлагается либо старое и убогое, либо новое, навороченное и жирное.

Я раньше писал на чистом винапи. Потом немного поковырял MFC, а в 2010 году познакомился с Qt. Теперь, так сказать, one love. Чистый и понянтый код фреймворка, адекватное внутреннее устройство и самая крутая документация из всех которые я видел.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>...

S>>А в чем проблема встроится, например, в Qt-шный event loop? Религия, квалификация?
ЕМ>Qt меня отвращает прежде всего своей монстроидальностью. Типовые варианты готовых DLL, заточенные на изготовление красивых и броских интерфейсов, очень тяжелы. Простейших, минимальных сборок, без украшений, с разумной функциональностью не дают. Чтобы их собрать, нужно вдумчиво разбираться в структуре, правилах настройки, сборки и т.п. Ну и Qt все строит вокруг себя. Он, как и MFC, должен господствовать в приложении, а мой код — быть подчиненным. Чтобы отобрать эту страсть к господству, нужно опять же вдумчиво разбираться. Когда нужно изготовить сложный и развесистый UI к приложению хотя бы на десяток мегабайт кода, Qt весьма неплох. В сочетании с моим кодом в сотню-другую килобайт оно будет смотреться по-дурацки.

Следите за руками. Статическая сборка, Qt lite, UPX, и оппа, рантайм становится меньше 5 мегабайт.

Вопрос в том, какие реальные задачи вы решаете?

Пока что судя по всей ветке складывается впечатление, что:
1) вы делаете что-то, чисто поиграться, без коммерческой ценности
2) вы просто так решили что надо максимально уменьшить размер .exe. (Привет ассемблер, менуэт/колибри ОС).
3) вам лень учить Qt / что-то ещё.

Здравствуйте, serj.e, Вы писали:

SE>Муз. программа Reaper, например, использует самодельное подмножество WinAPI, запускающееся на Винде, Маке, Линуксе. Уж не знаю, насколько в здравом уме автор этого подхода, но продукт получается отличный.

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

SE>А несравненный Blender весь UI отрисовывает сам на OpenGL.

SE>Если так не нравятся фреймворки, то почему бы сразу не взять какой-нибудь Dear Imgui, и не рисовать интерфейс самому?

ImGui выглядит очень интересно, спасибо. Мне как раз нравится идея с динамическим созданием элементов непосредственно из кода, поскольку рисование интерфейса в отдельном дизайнере хорошо лишь для статических раскладок (или требует управления компоновкой в стиле HTML/CSS). Буду посмотреть.

Здравствуйте, SaZ, Вы писали:

SaZ>Там в соседнем треде кинули проперти грид — так в деталях же захлебнуться можно на фоне любого внятного фреймворка.

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

SaZ>Жду от вас реальный пример контрола с кодом, который будет удовлетворять вашим требованиям.

Найду — поделюсь.

SaZ>Вы писали свои контролы?

Так, чтоб совсем с нуля — нет. Писал через Owner Draw обертки вокруг Picture Control, полностью отображающие себя сами, вокруг других — чуть меняющие поведение стандартных.

SaZ>А зачем вам использовать сразу всю возможную логику? Используйте только то, что вам нужно

Да я-то с удовольствием, но оно ж все равно тащит в EXE/DLL кучу зависимостей, от которых не избавиться никак, ибо на них завязан сам фреймворк.

SaZ>Опишите исходную решаемую задачу

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

SaZ>и вашу мотивацию к наитивным контролам

Главная мотивация — простота реализации, но не ценой увеличения размера приложения в десятки раз (сейчас там всего 100-150 кило байт). Я понимаю, что на Qt это делается кратко и изящно, но Qt непременно тащит за собой всю машинерию по отрисовке, платформо-независимые обертки над системными функциями и прочее. Поэтому хочется иметь реализации типовых элементов (список, таблица, сворачиваемое дерево, масштабируемый график и т.п.) или в виде классов C++, или в виде процедур, которые можно легко обернуть в классы.

Здравствуйте, удусекшл, Вы писали:

У>если мне не изменяет склероз, такие события всегда в один обработчик валились, с флажком нажато/отпущено. Ты, походу, вообще смотреть не пробовал, что как сделано, но заранее всё осуждаешь.

Я не осуждаю сам подход, а называю причины, по которым он не нравится лично мне. Разумеется, когда начинаешь знакомиться с чем-то новым, и сразу наталкиваешься на неудобные для себя правила, желание изучать дальше стремительно падает. Например, не могу заставить себя внимательно изучать те же Qt и Sciter, видя конечные объемы их кода, которые нужно тащить вместе с любым приложением. Люто, бешено завидую тем, кто или вовсе не обращает на это внимания, или сумел легко себя перебороть.