Re[11]: Реализации независимых элементов GUI под винду - C/C++. Прикладные вопросы

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

ЕМ>Кто какие знает реализации независимых (вне фреймворков) элементов GUI под винду, сделанных наподобие встроенных виндовых controls, и доступных в виде библиотек с произвольным выбором отдельных элементов?

Такое IMHO может сделать только сама Microsoft. Зачем кому-то еще такое делать.
Это же не будет ни интелисенса нормального, ни поддержки фреймворков, может быть будет использоваться 0.01% разработчиков.

ЕМ>Иногда хочется добавить какие-нибудь интеллектуальные элементы вроде настроек в стиле VS, но самому делать лень, а подключать для этого фреймворки — слишком накладно.

Я когда под винду писал, такие вещи на чем-то типа codeproject искались. Вот например PropertyGrid на чистом WinAPI
https://www.codeproject.com/Articles/77957/Win-SDK-PropertyGrid-Made-Easy

Я сам не пробовал. Поскольку самиздат, скорее всего будут глюки, с которыми придется героически бороться.

Не рассматривал вариант перейти на HTML? Плюс несколько мегабайт, и практически неограниченные возможности для UI. Под винду сейчас еще WebView2 появился.

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

bnk>>Я когда под винду писал, такие вещи на чем-то типа codeproject искались. Вот например PropertyGrid на чистом WinAPI
bnk>>https://www.codeproject.com/Articles/77957/Win-SDK-PropertyGrid-Made-Easy
AG>+100500
AG>Да,www.codeproject.com — великолепный ресурс.
AG>Я помню, когда работал над проектими с MFC и WinAPI — часто смотрел туда и брал некоторые интересные идеи и даже коды.

В своё время еще много тырил с https://www.viksoe.dk/

Кто какие знает реализации независимых (вне фреймворков) элементов GUI под винду, сделанных наподобие встроенных виндовых controls, и доступных в виде библиотек с произвольным выбором отдельных элементов?

Иногда хочется добавить какие-нибудь интеллектуальные элементы вроде настроек в стиле VS, но самому делать лень, а подключать для этого фреймворки — слишком накладно.

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

ЕМ>>Хочется именно автономных контролов, как стандартные виндовые, которые можно встроить в код любой парадигмы и структуры.
S>Вы хотите невозможного: любые контролы должны иметь свой event loop, цикл обрабоки сообщений или что-то подобное,

Чего?

S>А в чем проблема встроится, например, в Qt-шный event loop? Религия, квалификация?

Какой кутишный ивент-луп в виндовом приложении?

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

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

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

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

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

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

А вы пример можете привести? Делать полностью абстрактные контролы очень тяжело — нужно очень много писать руками, в том числе логику.
Фреймворки как раз призваны упростить разработку контролов. Сравните, к примеру, сложность реализации пользовательской логики для дерева из Qt (QTreeView) и винапишного.

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

ЕМ>>Типовые варианты готовых DLL, заточенные на изготовление красивых и броских интерфейсов, очень тяжелы.

S>Что значит тяжелы? ~20 мегабайт.

У меня самые тяжелые EXE — 120-150 кило байт x86, 170-200 — x64.

Для них даже 5-10 мегабайт чистого UI — это очень много, а 20 — неимоверно, чудовищно много.

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

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

S>Специальная сборка не нужна. qtwindeployqt устанавливает только то, что нужно.

И какой объем UI-кода он мне установит для добавления в приложения только базовой функциональности UI, без локализации, цветовых градиентов, анимации и прочих чисто эстетических плюшек?

ЕМ>>Чтобы их собрать, нужно вдумчиво разбираться в структуре, правилах настройки, сборки и т.п.
S>Да не нужно все это в 99% случаев.

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

S>Хочешь сам, хочешь используй стандартный Qt-шный подход:

И как я могу выдрать из Qt обработчики его отдельных элементов UI, чтобы вызывать их из своего цикла обработки сообщений, и чтобы они не тянули за собой всю инфраструктуру Qt, предназначенную для организации платформенно-независимой среды? Они же внутри себя, как я понимаю, работают не с WinAPI, а с элементами этой самой среды, которая составляет изрядную часть кода.

S>В чем проблема, если в дистрибутиве большая часть это гуёвая библиотека?
S>Думаешь кто-то будет смотреть процентное соотношение размеров разныех длл-ек после установки?

Это буду смотреть я сам.

Понимаю, что большинство юзеров сглотнет и не такое, но изготавливать технически убогий шлак мне претит.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SaZ>>Вам ничего не мешает собирать всё в один файл.
ЕМ>Какая разница, будет в составе один большой файл или несколько поменьше, если все они вместе будут десяти-двадцатикратно избыточны по коду?

Ещё раз, что значит "избыточны"? Не используйте никакие ОС, пишите машинными кодами под bare metal. Не создавайте проблему на пустом месте.

SaZ>>Вы опять же, описываете какие-то свои странные желания, уходя от того чтобы описать реальную проблему (которой, скорее всего нет).
ЕМ>Да, для тех, кто не считает мегабайты, проблемы действительно нет. А потом спрашивают, откуда берется bloatware.

-//-

SaZ>>С реальным временем вы перегнули, я уверен что задержка в 16-50мс на отрисовку будет не очень критична для пользователя, поскольку он её не заметит

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

Пруф будет? Такой софт как Virtual Dj мало того что рисует весь GUI через видеокарту, так они ещё используют GPU для создания звуковых эффектов в realtime.

SaZ>>В очередной раз вопрос — почему у вас появилось ограничение в 150 килобайт вместо 20 мегабайт?
ЕМ>Это не ограничение, а реальная оценка объема кода. Если у меня 100 кб кода логики, через WINAPI/GDI то, что мне нужно, реализуется еще в 50-100 кб, то 20 Мб будет аккурат в сто раз больше. Реальная проблема — не "20 Мб", а "объем в сто раз больше реально потребного".

Что вы понимаете под словом "потребного"? Повторюсь, почему вы не пишете машинными кодами под bare metal, а используете ОС и высокоуровневые языки?

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

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

SaZ>>какие накладные расходы? Быстродействие приложения вообще не зависит от размера бинарника.

ЕМ>Накладные — от слова "накладываться". Те расходы, что накладываются сверх реально потребных — хоть по объему, хоть по быстродействию, хоть по затратам на установку/сопровождение и т.п.

Вы скатываетесь в какой-то неадекватный троллинг. Это как для обычной легковой машине в такси заморачиваться не по поводу расхода топлива а по поводу отсутствия топовой резины. Тоже ведь колёса — это накладные расходы на трение.
В общем, конструктивных ответов на свои прямые вопросы я пока от вас не получил, не вижу смысла далее пытаться что-то посоветовать.

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

ЕМ>>>Кто какие знает реализации независимых (вне фреймворков) элементов GUI под винду, сделанных наподобие встроенных виндовых controls, и доступных в виде библиотек с произвольным выбором отдельных элементов?
bnk>>Такое IMHO может сделать только сама Microsoft. Зачем кому-то еще такое делать.
BFE>За деньги.

Я про то что контролами же надо как-то пользоваться. Не вижу рынка у контролов, с которым можно общаться только на голом WinAPI через SendMessage

Даже микрософтовские контролы без оберток практически не используются.

IMHO, вот так слона не продать (ну может Евгению разве что)

    SET_HOUR_MINUTE_OPTS param = {};
    param.cb = sizeof(SOME_DATA);
    param.hour = 10;
    param.minute = 22;

    ::SendMessage(hwndTimeControl, MSG_SET_HOUR_MINUTE, 0, &param);

Вот так можно попробовать:

timeControl.Hour = 10;
timeControl.Minute = 22;

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

SaZ>Ещё раз, что значит "избыточны"?

Это значит, что содержат и/или требуют количества ресурсов, значительно превышающего объективно потребные.

24 колеса в городском автомобиле — избыточны. 567 клавиш на стандартной компьютерной клавиатуре — избыточны. Разрешение 13" экрана в 16000x10000 — избыточно. Всего этого не делают по единственной причине — это потребует заметно больше труда и создаст заметно больше проблем, нежели добавление нового шаблонного класса.

SaZ>Не используйте никакие ОС, пишите машинными кодами под bare metal.

По-Вашему, это единственный способ избавиться от многократной избыточности кода/данных?

SaZ>Не создавайте проблему на пустом месте.

Если разработчики 24-колесного городского автомобиля или 567-клавишной клавиатуры на Ваш вопрос "на хрена столько?" дадут Вам такой же ответ — чем станете крыть?

ЕМ>>большие расходы времени на отрисовку будут грузить процессор, а использование аппаратного ускорения нередко приводит к тому, что видеодрайвер надолго (по меркам ядра) зависает на повышенных приоритетах. Все это не идет на пользу стабильности звуковых потоков при коротких буферах.

SaZ>Пруф будет?

До хренища, даже подбирать не буду — гуглите хотя бы LatencyMon и его результаты на разном железе с разными драйверами.

SaZ>Такой софт как Virtual Dj мало того что рисует весь GUI через видеокарту, так они ещё используют GPU для создания звуковых эффектов в realtime.

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

SaZ>Что вы понимаете под словом "потребного"?

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

SaZ>Повторюсь, почему вы не пишете машинными кодами под bare metal, а используете ОС и высокоуровневые языки?

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

Высокоуровневые языки я использую потому, что умею их готовить. Избыточность по сравнению с машинными кодами составляет 10-15% в самых узких местах, и 20-30% — в наименее критичных. А ресурсоемкость изготовления машинного кода той же функциональности была бы в разы выше. Вот такая простая арифметика.

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

зачем вы тратите время на Евгения ?
очевидно, если бы ему было нужно, он бы за пару часовой ресерчь в гугл/гитхаб нашел бы то то ему надо

даже хидер онли гуи по моему приводили в теме

но ему все не то, этакая принцесса несмеяна

а вообще я бы чуваков через 20 лет в ит программистами, за такие тупые вбросы, банил бы и опускал ниже полинтуса

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

ЕМ>А вот где сейчас активно используются технологии производства софта с адекватным расходом ресурсов?

Осталось договорится о терминологии. Что такое адекватный расход ресурсов? Адекватный чему?

ЕМ>Я от Вас вообще ничего конструктивного пока не получил...

Ты видимо всё, что не понравилось, записал в неконструктивное. Подход не новый...

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

ЕМ>Кто какие знает реализации независимых (вне фреймворков) элементов GUI под винду, сделанных наподобие встроенных виндовых controls, и доступных в виде библиотек с произвольным выбором отдельных элементов?

ЕМ>Иногда хочется добавить какие-нибудь интеллектуальные элементы вроде настроек в стиле VS, но самому делать лень, а подключать для этого фреймворки — слишком накладно.
Я как-то делал "умный" HotKeyCtrl, в который добавлял разные возможности: настроить как двойное нажатие клавиши, выбор сочетаний клавиш из контекстного меню, всякие нотификации добавлял на предмет настройки горячей клавишы изменены, или он занята и все такое.

Реализовывал на чистом C++ и только WinAPI-стиле. То бишь саму суть вышеперечисленную. Ну и реализации в стиле WinAPI: управление этим HotKey-контролом через сообщения, нотификации в стиле WinAPI (получили парент, отослали ему WM_NOTIFY с указателем на наследника от структуры NMHDR).

А потом уж добавил классы-обвязки для MFC, и WTL… Чисто для удобства и только — внутрях эти обвязки дергают это самое pure WinApi ядро.
Ибо абсолютно старые проекты — и переписывать саму суть заново для каждого фреймворка как-то заломало.

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

G6>Посмотри на WTL. Помимо самого WTL-я есть куча отдельных контролов на WTL-е в инете.

ATL/WTL я давно смотрел, но они оба фреймворки (подразумевают, что весь мой код строится вокруг них, и вызывается оттуда). В частности, не нравится (как и в MFC) идея делать отдельную функцию для обработки каждого сообщения — получается слишком громоздко, во многих случаях банальный switch записывается в несколько раз компактнее и яснее.

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

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

ЕМ>ATL/WTL я давно смотрел, но они оба фреймворки (подразумевают, что весь мой код строится вокруг них, и вызывается оттуда).
Что-то ты не туда смотрел. ATL/WTL просто шаблонные обмотки вокруг разных аспектов WinAPI и процедур окна. Они ничего не требуют от тебя больше. MFC — да, монстр фрейворк. ATL/WTL — нет.

ЕМ>В частности, не нравится (как и в MFC) идея делать отдельную функцию для обработки каждого сообщения — получается слишком громоздко, во многих случаях банальный switch записывается в несколько раз компактнее и яснее.
Зря ты, как раз очень удобно. Все параметры сообщений уже разобраны. Ты просто перекрываешь нужный метод и меняешь только то что нужно. Так тебе придется сабкласить окна и прокидывать все не нужные тебе сообщения пока ты сделаешь что-то нужное.

ЕМ>Хочется именно автономных контролов, как стандартные виндовые, которые можно встроить в код любой парадигмы и структуры.
Я использую WTL именно так как ты говоришь. Конкретнее в DirectShow Property Page-ах, которые вообще хрен знает кем создаются и вообще COM.

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

ЕМ>Хочется именно автономных контролов, как стандартные виндовые, которые можно встроить в код любой парадигмы и структуры.
Вы хотите невозможного: любые контролы должны иметь свой event loop, цикл обрабоки сообщений или что-то подобное, вся логика программы будет плясать от этого. Можно по максимому разделить ГУЙ и бизнес-логику, разбить их на 2 приложения.

А в чем проблема встроится, например, в Qt-шный event loop? Религия, квалификация?

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

ЕМ>ATL/WTL я давно смотрел, но они оба фреймворки (подразумевают, что весь мой код строится вокруг них, и вызывается оттуда). В частности, не нравится (как и в MFC) идея делать отдельную функцию для обработки каждого сообщения — получается слишком громоздко, во многих случаях банальный switch записывается в несколько раз компактнее и яснее.

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

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

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

SaZ>А вы пример можете привести?

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

SaZ>Делать полностью абстрактные контролы очень тяжело — нужно очень много писать руками, в том числе логику.

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

SaZ>Фреймворки как раз призваны упростить разработку контролов. Сравните, к примеру, сложность реализации пользовательской логики для дерева из Qt (QTreeView) и винапишного.

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

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

V>Что-то ты не туда смотрел. ATL/WTL просто шаблонные обмотки вокруг разных аспектов WinAPI и процедур окна.

В частности, смотрел сюда. Там, как и в MFC, все через CMainWindow/CMessageLoop — управление сразу же отдается WTL, который вызывает перекрытые методы своих классов.

V>Зря ты, как раз очень удобно.

И зачастую громоздко. Вместо одной функции на пару страниц с простым switch и частью общего кода, приходится писать несколько независимых функций, в которых этот общий код повторяется, или выносить его в дополнительную функцию. В итоге логика очень сильно размазывается.

V>Все параметры сообщений уже разобраны. Ты просто перекрываешь нужный метод и меняешь только то что нужно. Так тебе придется сабкласить окна и прокидывать все не нужные тебе сообщения пока ты сделаешь что-то нужное.

Какая связь между сабклассингом и способом передачи сообщений в мой код? Оно точно так же могло бы сразу вызывать у меня что-то вроде OnMessage (Msg, WP, LP). А там бы я либо использовал if/switch по Msg, либо вызывал какой-нибудь CrackMessage, который бы все разбирал и вызывал мои OnXxx. Это и раздражает, что вместе с полезным/удобным непременно навязывается что-нибудь бесполезное/неудобное.

V>Я использую WTL именно так как ты говоришь.

И как там избавиться от "канонических" компоновки кода и передачи управления, чтобы максимум того управления оставить себе?

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

S>любые контролы должны иметь свой event loop, цикл обрабоки сообщений

С чего вдруг? Они должны иметь свои оконные процедуры, которые будут вызываться из основного (и часто единственного) цикла обработки. А там они или могут все делать сами, если знают, как, или заранее оговоренным способом дергать мой код.

S>А в чем проблема встроится, например, в Qt-шный event loop? Религия, квалификация?

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

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

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

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

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

V>>Что-то ты не туда смотрел. ATL/WTL просто шаблонные обмотки вокруг разных аспектов WinAPI и процедур окна.

ЕМ>В частности, смотрел сюда. Там, как и в MFC, все через CMainWindow/CMessageLoop — управление сразу же отдается WTL, который вызывает перекрытые методы своих классов.

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

ЕМ>И зачастую громоздко. Вместо одной функции на пару страниц с простым switch и частью общего кода, приходится писать несколько независимых функций, в которых этот общий код повторяется, или выносить его в дополнительную функцию. В итоге логика очень сильно размазывается.

Я писал и на на одном switch, и на WTL. На WTL гораздо проще, там зачастую всё уже написано, надо только дёрнуть подходящее

ЕМ>Какая связь между сабклассингом и способом передачи сообщений в мой код? Оно точно так же могло бы сразу вызывать у меня что-то вроде OnMessage (Msg, WP, LP). А там бы я либо использовал if/switch по Msg, либо вызывал какой-нибудь CrackMessage, который бы все разбирал и вызывал мои OnXxx. Это и раздражает, что вместе с полезным/удобным непременно навязывается что-нибудь бесполезное/неудобное.

Ну и кто тебе мешает писать на чистом WinAPI?

V>>Я использую WTL именно так как ты говоришь.

ЕМ>И как там избавиться от "канонических" компоновки кода и передачи управления, чтобы максимум того управления оставить себе?

Тащем-то, в WTL есть "карта" сообщений, которая строиться из макросов, которые на самом деле есть if'ы с message cracker'ами. И тебе никто не мешает туда запендюрить свои if'ы и делать в них всё, что твоей душе угодно

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

ЕМ>С чего вдруг? Они должны иметь свои оконные процедуры, которые будут вызываться из основного (и часто единственного) цикла обработки. А там они или могут все делать сами, если знают, как, или заранее оговоренным способом дергать мой код.
В Qt можно и так, явно вызвать обработку сообщений когда тебе удобно.
QEventLoop::processEvents

ЕМ>Qt меня отвращает прежде всего своей монстроидальностью. Типовые варианты готовых DLL, заточенные на изготовление красивых и броских интерфейсов, очень тяжелы.
Что значит тяжелы? ~20 мегабайт.
vc_redist.x64.exe — 16 мегабайт.

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

ЕМ>Чтобы их собрать, нужно вдумчиво разбираться в структуре, правилах настройки, сборки и т.п.
Да не нужно все это в 99% случаев.

ЕМ>Ну и Qt все строит вокруг себя. Он, как и MFC, должен господствовать в приложении, а мой код — быть подчиненным.
Это какая-то религия пошла... ГУЙ — он событийно-управляемый, кто-то должен запускать обработчик сообщений. Хочешь сам, хочешь используй стандартный Qt-шный подход:

int main(int argc, char *argv[])
{
    Application application(argc, argv);
    return application.exec();
}

ЕМ>Чтобы отобрать эту страсть к господству, нужно опять же вдумчиво разбираться.
И никакого выигрыша ты не получишь.

ЕМ>Когда нужно изготовить сложный и развесистый UI к приложению хотя бы на десяток мегабайт кода, Qt весьма неплох. В сочетании с моим кодом в сотню-другую килобайт оно будет смотреться по-дурацки.
А какая разница, какого размера у тебя бизнес-логика? В чем проблема, если в дистрибутиве большая часть это гуёвая библиотека?
Думаешь кто-то будет смотреть процентное соотношение размеров разныех длл-ек после установки?

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

ЕМ>В частности, смотрел сюда. Там, как и в MFC, все через CMainWindow/CMessageLoop — управление сразу же отдается WTL, который вызывает перекрытые методы своих классов.

Названия такие же или похожи, но принцип совершенно другой. Это другой CMainWindow и другой CWindow. В WTL ты спокойно можешь прицепиться к WinAPI окну которое о нем знать не знает и спокойно с ним работать.

ЕМ>И зачастую громоздко. Вместо одной функции на пару страниц с простым switch и частью общего кода, приходится писать несколько независимых функций, в которых этот общий код повторяется, или выносить его в дополнительную функцию. В итоге логика очень сильно размазывается.

Странно считать что разделение связанной логики по разным функция что-то там "размазывает". Сейчас в программировании это наоборот тренд: все становится функциональным. Кругом маленькие "чистые" функции на каждый чих. Все равно что заявить: что для вызова любой функции нужен только указатель и AX, BX, CX, DX... все остальное это размазывание. (шучу

)

ЕМ>Какая связь между сабклассингом и способом передачи сообщений в мой код? Оно точно так же могло бы сразу вызывать у меня что-то вроде OnMessage (Msg, WP, LP). А там бы я либо использовал if/switch по Msg, либо вызывал какой-нибудь CrackMessage, который бы все разбирал и вызывал мои OnXxx. Это и раздражает, что вместе с полезным/удобным непременно навязывается что-нибудь бесполезное/неудобное.

Такая что к каждому окну по умолчанию привязана функция обработчик, и если ты хочешь хоть на миллиметр отклониться от дефолтного поведения, то ты должен сабкласить функцию окна. Другими словами ты должен подставить свою функцию, где ты будешь менять только то поведение, которое отличается от стандартного. С С++ под эту основу один в один ложатся классы обертки и их наследование друг от друга. И да, в WinAPI эта аналогия не до конца такая же. Если проводить аналогию с классами С++, то в WinAPI можно подменить таблицу виртуальных функций у отдельного экземпляра класса.

ЕМ>И как там избавиться от "канонических" компоновки кода и передачи управления, чтобы максимум того управления оставить себе?

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

Я, например, у себя никакого event-loop не создаю. Я вообще не знаю кто и как его создает, т.к. меня вызывает стороннее приложение и все замечательно работает. Поверь, ATL/WTL это не MFC, хотя MFC используют их если нужно.

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

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

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

У>Ну и кто тебе мешает писать на чистом WinAPI?

Его недостаточная функциональность.

А как только пытаюсь использовать что-то стороннее — оно или навязывает свою парадигму, или тянет за собой слишком много зависимостей, или еще что.

У>в WTL есть "карта" сообщений, которая строиться из макросов, которые на самом деле есть if'ы

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

Еще меня много лет тормозило в использовании сторонних средств то, что я когда-то давно сделал себе небольшое подмножество CRT, чтобы не тащить в EXE лишние зависимости, и заодно лучше контролировать ошибки памяти. На мелких утилитах это давало трех-пятикратное уменьшение размера EXE, вместе с ранней ловлей распространенных ляпов. А потом настолько привык работать внутри этого подмножества, что вылезать за его пределы стало даже как-то некомфортно.

Теперь логика UI в некоторых приложениях разрослась настолько, что обрезание CRT уже перестало давать заметное уменьшение EXE, так что надо заставить себя использовать и сторонние средства.

Здравствуйте, 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 к хендлу нужного окна. Сама процедура окна, на сколько я помню, сабкласится, но тутже вызывает старую, и ты спокойно можешь переопределять только то что нужно.

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

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

ЕМ>У меня самые тяжелые 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 в достаточно широких пределах, вовсе не обязательно сабклассить функцию окна — достаточно задать стили при создании элемента, или послать управляющие сообщения после этого, или обрабатывать сообщения, посылаемые им родителю.

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

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

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

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

ЕМ>Вздор. Чтобы менять стиль поведения того же 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, и в нем дополнительно ветвиться по коду сообщения.

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

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

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

У>>Приведи пример, когда 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-х контролов — вы рано или поздно изобретёте свой фреймворк, ну или наймёте отдел индусов для поддержки.

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

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

ЕМ>...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я не осуждаю сам подход, а называю причины, по которым он не нравится лично мне.

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

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

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

Так это все равно в десятки раз больше, чем я имею сейчас, и чем если я сделаю свой UI практически с нуля. Если бы Qt был стандартным элементом винды хотя бы начиная с Win7, или устанавливался бы туда один раз, как .NET Framework, а затем использовался всеми приложениями сразу — я бы давно на него перешел. Но необходимость тащить с собой многократно избыточный объем кода в каждом приложении мне настолько неприятна, что пока ничего не могу с собой поделать.

SaZ>1) вы делаете что-то, чисто поиграться, без коммерческой ценности

Вот как раз такое я могу делать и на Qt, и на Sciter, тут внутреннее сопротивление минимально.

SaZ>2) вы просто так решили что надо максимально уменьшить размер .exe. (Привет ассемблер, менуэт/колибри ОС).

Не "максимально", а разумно. Накладные расходы в 20-30%, даже в 50% можно потерпеть, но тысячи процентов — это уже перебор. И неважно, что большинство разработчиков давно потеряло (или вообще никогда не имело) способность соотносить функциональность с потребным объемом кода. У меня-то она еще сохранилась.

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

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

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

Вы опять же, описываете какие-то свои странные желания, уходя от того чтобы описать реальную проблему (которой, скорее всего нет).

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

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

С реальным временем вы перегнули, я уверен что задержка в 16-50мс на отрисовку будет не очень критична для пользователя, поскольку он её не заметит

Хотите быстро рисовать — откажитесь от WinAPI/GDI и используйте ну хотя-бы OpenGL. Опять же, в Qt это можно в несколько строк кода сделать. А ещё лучше — сразу написать компонент QtQuick. Тем более там из коробки есть графики, правда под GPL либо платной лицензией.

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

В очередной раз вопрос — почему у вас появилось ограничение в 150 килобайт вместо 20 мегабайт?

Если вам надо писать компактный и быстрый софт под специальное железо и у вас УЖЕ ЕСТЬ реальные проблемы с производительностью — переходите на ассемблер. Иначе — вы просто сами себе создаёте проблемы на пустом месте.
Я как-то раз выводил графики на аудио пульте под управлением Windows ME, но там был готовый АПИ

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

ЕМ>Не "максимально", а разумно. Накладные расходы в 20-30%, даже в 50% можно потерпеть, но тысячи процентов — это уже перебор. И неважно, что большинство разработчиков давно потеряло (или вообще никогда не имело) способность соотносить функциональность с потребным объемом кода. У меня-то она еще сохранилась.

Стоп, какие накладные расходы? Быстродействие приложения вообще не зависит от размера бинарника.

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

SaZ>Вам ничего не мешает собирать всё в один файл.

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

SaZ>Вы опять же, описываете какие-то свои странные желания, уходя от того чтобы описать реальную проблему (которой, скорее всего нет).

Да, для тех, кто не считает мегабайты, проблемы действительно нет. А потом спрашивают, откуда берется bloatware.

SaZ>С реальным временем вы перегнули, я уверен что задержка в 16-50мс на отрисовку будет не очень критична для пользователя, поскольку он её не заметит

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

SaZ>В очередной раз вопрос — почему у вас появилось ограничение в 150 килобайт вместо 20 мегабайт?

Это не ограничение, а реальная оценка объема кода. Если у меня 100 кб кода логики, через WINAPI/GDI то, что мне нужно, реализуется еще в 50-100 кб, то 20 Мб будет аккурат в сто раз больше. Реальная проблема — не "20 Мб", а "объем в сто раз больше реально потребного".

SaZ>Если вам надо писать компактный и быстрый софт под специальное железо и у вас УЖЕ ЕСТЬ реальные проблемы с производительностью — переходите на ассемблер.

Спасибо, я и на C++ почти все пишу почти не хуже, чем на ассемблере, когда мне не лень следить за кодогенерацией.

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

SaZ>какие накладные расходы? Быстродействие приложения вообще не зависит от размера бинарника.

Накладные — от слова "накладываться". Те расходы, что накладываются сверх реально потребных — хоть по объему, хоть по быстродействию, хоть по затратам на установку/сопровождение и т.п.

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

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

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

Аналогия кривая. Гадить — это приложение на java или js которое воздух греет.

S>>В линухе в общем случае это не так. Но особо популярные приложения всеже тащат свои либы чтобы уменьшить вероятность проблем на стороне пользователя.
ЕМ>Они их тащат исключительно для себя, или другое подобное приложение тоже сможет использовать установленные экземпляры этих либ?
Для себя, но это исключение, а не правило.

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

Да нормально воспринимать.

ЕМ>>>Так в этих случаях получается перевес объема кода UI над логикой в несколько раз минимум.
S>>Да и пофиг.
ЕМ>Когда всем пофиг — это деградация.
Никакой проблемы в соотношении GUI/логиака нет. GUI это тоже логика, только шаблонная и сделаная другими.

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

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

ЕМ>>Кто какие знает реализации независимых (вне фреймворков) элементов GUI под винду, сделанных наподобие встроенных виндовых controls, и доступных в виде библиотек с произвольным выбором отдельных элементов?
bnk>Такое IMHO может сделать только сама Microsoft. Зачем кому-то еще такое делать.
За деньги.

bnk>Это же не будет ни интелисенса нормального, ни поддержки фреймворков, может быть будет использоваться 0.01% разработчиков.
Сейчас — да, а раньше был целый рынок контролов под винду.

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

SaZ>Это как для обычной легковой машине в такси заморачиваться не по поводу расхода топлива а по поводу отсутствия топовой резины.

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

SaZ>В общем, конструктивных ответов на свои прямые вопросы я пока от вас не получил

Я от Вас вообще ничего конструктивного пока не получил...

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

bnk>Не вижу рынка у контролов, с которым можно общаться только на голом WinAPI через SendMessage

Что значит "только"? Сделать ООП-обертку для управления через SendMessage гораздо проще, чем написать весь код с нуля в том же ООП.

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

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

ЕМ>Что значит "только"? Сделать ООП-обертку для управления через SendMessage гораздо проще, чем написать весь код с нуля в том же ООП.

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

Чтобы сделать в стиле ооп, придется решить ряд инфраструктурных задач, что эта требуха и делает..
Как минимум это:

— маппинг hwnd на объекты
— маппинг сообщений на обработчики
— поддержка тем винды при отрисовке

Вроде WTL например ничего другого и не добавляет в принципе

Оверхед самый что ни на есть минимальный. Все определения в хидерах, рантайма нет.

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

Насколько я помню размер измеряемый в килобайтах вполне реален.

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

R>зачем вы тратите время на Евгения ?
R>очевидно, если бы ему было нужно, он бы за пару часовой ресерчь в гугл/гитхаб нашел бы то то ему надо
R>даже хидер онли гуи по моему приводили в теме

Ну WTL был популярен довольно недолго, хотя да упоминали. Но может если сказать два раза, это будет иметь больший вес?

И в принципе оверхед таки небольшой, CMyApp вроде не требовался, если мне не изменяет память.

R>но ему все не то, этакая принцесса несмеяна

У меня похожее чувство, но кто сказал что это плохо? Должны же быть хранители?

R>а вообще я бы чуваков через 20 лет в ит программистами, за такие тупые вбросы, банил бы и опускал ниже полинтуса

Злой ты. А как же гласность и плюрализм?

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

ЕМ>Кто какие знает реализации независимых (вне фреймворков) элементов GUI под винду, сделанных наподобие встроенных виндовых controls, и доступных в виде библиотек с произвольным выбором отдельных элементов?

https://www.tecgraf.puc-rio.br/iup/
https://github.com/andlabs/libui

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

bnk>Вроде WTL например ничего другого и не добавляет в принципе

Оверхед самый что ни на есть минимальный.

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

bnk>Все определения в хидерах, рантайма нет.

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

bnk>Размер обычно увеличивается, потому что UI библиотека должна решать эту задачу также для встроенных контролов

Как раз эти объемы весьма скромны — десятки килобайт максимум.

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

bnk>Ну WTL был популярен довольно недолго, хотя да упоминали.

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

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

bnk>Я когда под винду писал, такие вещи на чем-то типа codeproject искались. Вот например PropertyGrid на чистом WinAPI
bnk>https://www.codeproject.com/Articles/77957/Win-SDK-PropertyGrid-Made-Easy
+100500
Да,www.codeproject.com — великолепный ресурс.
Я помню, когда работал над проектими с MFC и WinAPI — часто смотрел туда и брал некоторые интересные идеи и даже коды.

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

ЕМ>Если разработчики 24-колесного городского автомобиля или 567-клавишной клавиатуры на Ваш вопрос "на хрена столько?" дадут Вам такой же ответ — чем станете крыть?

Ну, если уже есть 24х-колёсные автомобили, и стоят так же как и 4х-колёсные, или даже дешевле, почему бы и не на 24х колёсах ездить?

ЕМ>А какими объективными факторами Вы можете оправдать избыточность кода/данных современного софта в десятки раз, кроме того, что "пипл хавает" и "не вижу проблемы"?

Избыточность там только потому, что в них запихано на все случаи жизни, и если ты это не используешь — это твоя проблема. Зато, если использовать такие фреймворки, заметно снижается время на разработку.

Плюс, тебе вроде уже говорили — можешь купить Qt, и собирать в статические либы, из которых будет линковаться только то, что реально нужно. И вместо 20 метров либ у тебя будет только EXE метра на три. А три метра или 300 кил — это уже вот точно всем пофик.

Ну и это почти с любыми либами так. Хз, правда, насчёт MFC.
А вот та же WTL прибавит (если вообще прибавит) к твоему EXE несколько десятков кб, зато писать на ней на порядок проще (и быстрее), чем на винапи

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

bnk>>Это же не будет ни интелисенса нормального, ни поддержки фреймворков, может быть будет использоваться 0.01% разработчиков.
BFE>Сейчас — да, а раньше был целый рынок контролов под винду.

Рынок контролов под винду? Хм, что-то не припоминаю. Был рынок контролов для MFC, был для дельфячки. А вот чтоб вот так просто чисто винапишные контролы — не припоминаю

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

bnk>>Не вижу рынка у контролов, с которым можно общаться только на голом WinAPI через SendMessage

ЕМ>Что значит "только"? Сделать ООП-обертку для управления через SendMessage гораздо проще, чем написать весь код с нуля в том же ООП.

Ну не скажи, не скажи

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

Ну попробуй ты уже WTL, что ли

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

bnk>>Вроде WTL например ничего другого и не добавляет в принципе

Оверхед самый что ни на есть минимальный.

ЕМ>К WTL претензий нет — она действительно позволяет делать компактные приложения. Претензии к Qt, Sciter и подобным фреймворкам, в коде которых заложено множество возможностей, но почти все они намертво прибиты гвоздями, и затаскиваются в EXE/DLL практически безусловно.

Ну не используй ты Qt, Sciter и пр, не используй.

Sciter, кстати, нежирный вроде, там DLLка кил на 600 вроде, и всё. Но там полноценный рендеринг HTML с поддержкой CSS и свой скриптовый движок.

А кути — так это вообще на все случаи жизни практически.

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

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

У>Sciter, кстати, нежирный вроде, там DLLка кил на 600 вроде, и всё. Но там полноценный рендеринг HTML с поддержкой CSS и свой скриптовый движок.

Увы-увы. 600кб он был десять лет назад. Сейчас это уже мегабайты. С новым жаваскриптовым движком под 10 будет.

Здравствуйте, удусекшл, Вы писали:
У>Ну и это почти с любыми либами так. Хз, правда, насчёт MFC.

MFC за бесплатно умеет в виде статической либы.
Причем там классы по cpp мелкими кучками рассыпаны, чтобы лишнего меньше линковалось.

Фреймворком навязывается только одна глобальная переменная theApp.

В свое время делал кучу компактных утилит на MFC без внешних зависимостей (в т.ч. от msvcrt.dll).

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

У>>Sciter, кстати, нежирный вроде, там DLLка кил на 600 вроде, и всё. Но там полноценный рендеринг HTML с поддержкой CSS и свой скриптовый движок.

bnk>Увы-увы. 600кб он был десять лет назад. Сейчас это уже мегабайты. С новым жаваскриптовым движком под 10 будет.

Кстати, сейчас проверил на простом приложении, которому ни сеть не нужна, ни COM-порты, ни CAN, ничего ничего — ему лрстаточно qtcore.dll; вместе с приложухой всё весит чуть больше 8Мб. Не особо и много-то

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

У>если уже есть 24х-колёсные автомобили, и стоят так же как и 4х-колёсные, или даже дешевле, почему бы и не на 24х колёсах ездить?

Если они не только стоят столько же, но и занимают столько же места на парковке, потребляют столько же топлива и других расходников (шины — расходник), выбрасывают столько же продуктов сгорания, требуют столько же времени и денег на обслуживание и ремонт, и так далее — почему бы и нет? Но bloatware "стоит столько же" лишь на первый взгляд. Да, его дешево сделать и им дешево (в условиях сложившегося избытка ресурсов) пользоваться, но по сути это — информационный мусор. И разнообразного вреда от него изрядно, просто он не бросается в глаза. Главный же вред, на мой взгляд — в насаждении подхода "давайте делать так просто потому, что можно".

	Автопозиционирование не срабатывает, смотреть с 1:17:50

Не имея возможности это остановить, я хотя бы пытаюсь в этом не участвовать.

Не хочу делать дерьмо лишь потому, что это модно.

У>Избыточность там только потому, что в них запихано на все случаи жизни, и если ты это не используешь — это твоя проблема.

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

У>Зато, если использовать такие фреймворки, заметно снижается время на разработку.

Если при замене масла в двигателе сливать отработку на землю — заметно снижается время на процедуру (не нужно собирать в отдельную емкость, везти в пункт утилизации, да еще и платить за это).

У>Плюс, тебе вроде уже говорили — можешь купить Qt, и собирать в статические либы, из которых будет линковаться только то, что реально нужно. И вместо 20 метров либ у тебя будет только EXE метра на три. А три метра или 300 кил — это уже вот точно всем пофик.

Тем, кому пофиг на три метра, пофиг и на двадцать. А мне не пофиг прежде всего на относительные цифры, а не абсолютные. Если я наделаю собственного кода на десять метров — с чего бы меня стали парить еще пять-десять метров кода GUI? А когда код GUI вдесятеро толще собственного кода приложения — это оправдано исключительно для "hello, world".

Посмотрите, например, на Process Explorer, оцените функциональность и логики, и интерфейса. А там всего полтора мегабайта, непакованных, и внутри еще лежат драйвер ядра, который извлекается и ставится в систему, и тексты EULA на двух языках. На чем сделан GUI, навскидку не видно — подозреваю, что на ATL/WTL.

У>А вот та же WTL прибавит (если вообще прибавит) к твоему EXE несколько десятков кб, зато писать на ней на порядок проще (и быстрее), чем на винапи

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

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

У>Что такое адекватный расход ресурсов? Адекватный чему?

Я ж говорил — реализуемой функциональности, быстродействию. Если на ассемблере в допентиумную эпоху можно было делать код с накладными расходами, лишь на единицы процентов превосходящими теоретически возможные, то на C/C++/Pascal они и посейчас получаются не выше 10-30%, если особо не косячить. А код большинства современных библиотек, судя по размеру и потребным ресурсам, пишется на чем-то вроде питона.

У>Ты видимо всё, что не понравилось, записал в неконструктивное.

Не все, а только предложения вроде "не парься, пять-десять мегабайт — это ерунда, сейчас у всех так".

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

ЕМ>...

Очень не хватает кнопочки "facepalm" для оценки сообщений

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

Этот нюанс должен быть очевидным, но всё же лучше его упомянуть. 90% сложности любого UI – это текст. Отсюда следствие: если в продукте нет арабской вязи, CJK, иврита, полного набора эмодзи, чередования LTR/RTL, а также UI–контента, генерируемого не вами — рассматривать подобные легковесные библиотеки можно и нужно. Если же что-либо из перечисленного есть, или планируется, то сразу нет. Увязнете.

А так-то да, посмотрите. На Dear Imgui уже делают не только редакторы уровней и game tooling'и. На биржевые дела он тоже концептуально неплохо ложится: https://user-images.githubusercontent.com/8225057/105607011-af2a5300-5d9c-11eb-9bc8-39d3310e2192.jpg

От:	bnk	http://unmanagedvisio.com/
Дата:	10.03.21 14:16
Оценка:	14 (2) +1

	От:	McQwerty
	Дата:	11.02.21 13:33
	Оценка:	12 (1) -1

	От:	удусекшл
	Дата:	23.03.21 10:20
	Оценка:	10 (1) +1

От:	Евгений Музыченко	https://software.muzychenko.net/ru
Дата:	11.02.21 07:19
Оценка:	2 (1) -1

	От:	удусекшл
	Дата:	10.03.21 08:35
	Оценка:

От:	reversecode	google
Дата:	20.03.21 14:05
Оценка:	+1

От:	Carc	https://vk.com/gosha_mazov
Дата:	11.02.21 11:36
Оценка:

От:	Videoman	https://hts.tv/
Дата:	09.03.21 16:18
Оценка:

	От:	SaZ
	Дата:	12.03.21 13:31
	Оценка:	+1

	От:	SaZ
	Дата:	15.03.21 20:22
	Оценка:	-1

	От:	SaZ
	Дата:	15.03.21 20:25
	Оценка:	-1

	От:	gwg-605
	Дата:	08.03.21 23:35
	Оценка: