ЕМ>Если разработчики 24-колесного городского автомобиля или 567-клавишной клавиатуры на Ваш вопрос "на хрена столько?" дадут Вам такой же ответ — чем станете крыть?
Ну, если уже есть 24х-колёсные автомобили, и стоят так же как и 4х-колёсные, или даже дешевле, почему бы и не на 24х колёсах ездить?
ЕМ>А какими объективными факторами Вы можете оправдать избыточность кода/данных современного софта в десятки раз, кроме того, что "пипл хавает" и "не вижу проблемы"?
Избыточность там только потому, что в них запихано на все случаи жизни, и если ты это не используешь — это твоя проблема. Зато, если использовать такие фреймворки, заметно снижается время на разработку.
Плюс, тебе вроде уже говорили — можешь купить Qt, и собирать в статические либы, из которых будет линковаться только то, что реально нужно. И вместо 20 метров либ у тебя будет только EXE метра на три. А три метра или 300 кил — это уже вот точно всем пофик.
Ну и это почти с любыми либами так. Хз, правда, насчёт MFC.
А вот та же WTL прибавит (если вообще прибавит) к твоему EXE несколько десятков кб, зато писать на ней на порядок проще (и быстрее), чем на винапи
Re[11]: Реализации независимых элементов GUI под винду
bnk>>Это же не будет ни интелисенса нормального, ни поддержки фреймворков, может быть будет использоваться 0.01% разработчиков. BFE>Сейчас — да, а раньше был целый рынок контролов под винду.
Рынок контролов под винду? Хм, что-то не припоминаю. Был рынок контролов для MFC, был для дельфячки. А вот чтоб вот так просто чисто винапишные контролы — не припоминаю
Re[5]: Реализации независимых элементов GUI под винду
Здравствуйте, Евгений Музыченко, Вы писали:
bnk>>Не вижу рынка у контролов, с которым можно общаться только на голом WinAPI через SendMessage
ЕМ>Что значит "только"? Сделать ООП-обертку для управления через SendMessage гораздо проще, чем написать весь код с нуля в том же ООП.
Ну не скажи, не скажи
ЕМ>Мне не нужно, чтобы элементы непременно управлялись через SendMessage. Нехай будут в виде классов, лишь бы код одного элемента, компилирующийся, скажем, в 20 кб, не тащил за собой еще пару мегабайт требухи, которую я никогда не буду использовать.
Ну попробуй ты уже WTL, что ли
Re[7]: Реализации независимых элементов GUI под винду
Здравствуйте, Евгений Музыченко, Вы писали:
bnk>>Вроде WTL например ничего другого и не добавляет в принципе Оверхед самый что ни на есть минимальный.
ЕМ>К WTL претензий нет — она действительно позволяет делать компактные приложения. Претензии к Qt, Sciter и подобным фреймворкам, в коде которых заложено множество возможностей, но почти все они намертво прибиты гвоздями, и затаскиваются в EXE/DLL практически безусловно.
Ну не используй ты Qt, Sciter и пр, не используй.
Sciter, кстати, нежирный вроде, там DLLка кил на 600 вроде, и всё. Но там полноценный рендеринг HTML с поддержкой CSS и свой скриптовый движок.
А кути — так это вообще на все случаи жизни практически.
Не нравится объем пресобраных либ — ну собирай сам, только с тем, что нужно. Вообще вот не могу понять, что тебе ещё надо. С такими разговорами надо в "философию программирования" или вообще в "о жизни". Там как раз в тему поплакаться, какая нынче трава не зелёная, и деревья маленькие
Re[3]: Реализации независимых элементов GUI под винду
Здравствуйте, 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 — часто смотрел туда и брал некоторые интересные идеи и даже коды.
Здравствуйте, удусекшл, Вы писали:
У>Sciter, кстати, нежирный вроде, там DLLка кил на 600 вроде, и всё. Но там полноценный рендеринг HTML с поддержкой CSS и свой скриптовый движок.
Увы-увы. 600кб он был десять лет назад. Сейчас это уже мегабайты. С новым жаваскриптовым движком под 10 будет.
Re[12]: Реализации независимых элементов GUI под винду
Здравствуйте, bnk, Вы писали:
У>>Sciter, кстати, нежирный вроде, там DLLка кил на 600 вроде, и всё. Но там полноценный рендеринг HTML с поддержкой CSS и свой скриптовый движок.
bnk>Увы-увы. 600кб он был десять лет назад. Сейчас это уже мегабайты. С новым жаваскриптовым движком под 10 будет.
Кстати, сейчас проверил на простом приложении, которому ни сеть не нужна, ни COM-порты, ни CAN, ничего ничего — ему лрстаточно qtcore.dll; вместе с приложухой всё весит чуть больше 8Мб. Не особо и много-то
Re[12]: Реализации независимых элементов GUI под винду
Здравствуйте, удусекшл, Вы писали: У>если уже есть 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%, если особо не косячить. А код большинства современных библиотек, судя по размеру и потребным ресурсам, пишется на чем-то вроде питона.
У>Ты видимо всё, что не понравилось, записал в неконструктивное.
Не все, а только предложения вроде "не парься, пять-десять мегабайт — это ерунда, сейчас у всех так".
Re[13]: Реализации независимых элементов GUI под винду
ЕМ>ImGui выглядит очень интересно, спасибо. Мне как раз нравится идея с динамическим созданием элементов непосредственно из кода, поскольку рисование интерфейса в отдельном дизайнере хорошо лишь для статических раскладок (или требует управления компоновкой в стиле HTML/CSS). Буду посмотреть.
Этот нюанс должен быть очевидным, но всё же лучше его упомянуть. 90% сложности любого UI – это текст. Отсюда следствие: если в продукте нет арабской вязи, CJK, иврита, полного набора эмодзи, чередования LTR/RTL, а также UI–контента, генерируемого не вами — рассматривать подобные легковесные библиотеки можно и нужно. Если же что-либо из перечисленного есть, или планируется, то сразу нет. Увязнете.
