Информация об изменениях

Сообщение Re[12]: Реализации независимых элементов GUI под винду от 25.03.2021 11:08

Изменено 25.03.2021 11:52 Евгений Музыченко

Re[12]: Реализации независимых элементов GUI под винду
Здравствуйте, удусекшл, Вы писали:

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


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

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

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


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

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


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

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


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

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

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


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