История изменений

Ну те же поля ввода и комбобоксы вполне могут ресайзится при изменении размера окна (а у них есть рамочки, градиенты и т. д.). С layout'ми кнопки тоже вполне могут это делать. А тулкит должен поддерживать возможность построения любых интерфейсов. Кнопка, занимающая всегда определённый процент окна, может пригодится в каких-то случаях. Да можно просто вспомнить про мониторы с разным DPI. Если все элементы интерфейса (включая кнопки, полосы прокрутки и т. д.) будут масштабироваться в векторном виде, то интрефейс будет выглядеть значительно приятнее. Если этого не делать вообще (захардкодить все размеры), то на HighDPI дисплее всё будет жутко мелкое, если делать как в винде (растровое масштабирование), то получается дикое мыло и в итоге на мониторе с низким DPI изображение качественнее, чем на HighDPI, чего быть не должно. Конечно, можно свято верить, что DPI всегда равен 96, кнопочки всегда имеют одинаковую высоту и пикселях и это не может измениться в ходе работы программы (то что в иксах иногда глючит определение DPI и нет возможности поменять его при подключении нового монитора без перезапуска приложения-клиента - проблема иксов, это не значит, что тулкитам надо забить на эту возможность, благо Wayland на подходе), но уже сейчас есть ситуации, когда это не верно.

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

Ну те же поля ввода и комбобоксы вполне могут ресайзится при изменении размера окна (а у них есть рамочки, градиенты и т. д.). С layout'ми кнопки тоже вполне могут это делать. А тулкит должен поддерживать возможность построения любых интерфейсов. Кнопка, занимающая всегда определённый процент окна, может пригодится в каких-то случаях. Да можно просто вспомнить про мониторы с разным DPI. Если все элементы интерфейса (включая кнопки, полосы прокрутки и т. д.) будут масштабироваться в векторном виде, то интрефейс будет выглядеть значительно приятнее. Если этого не делать вообще (захардкодить все размеры), то на HighDPI дисплее всё будет жутко мелкое, если делать как в винде (растровое масштабирование), то получается дикое мыло и в итоге на мониторе с низким DPI изображение качественнее, чем на HighDPI, чего быть не должно. Конечно, можно свято верить, что DPI всегда равен 96, кнопочки всегда имеют одинаковую высоту и пикселях и это не может измениться в ходе работы программы (то что в иксах иногда глючит определение DPI и нет возможности поменять его при подключении нового монитора без перезапуска приложения-клиента - проблема иксов, это не значит, что тулкитам сделает забить на эту возможность, благо Wayland на подходе), но уже сейчас есть ситуации, когда это не верно.

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

Ну те же поля ввода и комбобоксы вполне могут ресайзится при изменении размера окна (а у них есть рамочки, градиенты и т. д.). С layout'ми кнопки тоже вполне могут это делать. А тулкит должен поддерживать возможность построения любых интерфейсов. Кнопка, занимающая всегда определённый процент окна, может пригодится в каких-то случаях. Да можно просто вспомнить про мониторы с разным DPI. Если все элементы интерфейса (включая кнопки, полосы прокрутки и т. д.) будут масштабироваться в векторном виде, то интрефейс будет выглядеть значительно приятнее. Если этого не делать вообще (захардкодить все размеры), то на HighDPI дисплее всё будет жутко мелкое, если делать как в винде (растровое масштабирование), то получается дикое мыло и в итоге на мониторе с низким DPI изображение качественнее, чем на HighDPI, чего быть не должно. Конечно, можно свято верить, что DPI всегда равен 96, кнопочки всегда имеют одинаковую высоту и пикселях и это не может измениться в ходе работы программы, но уже сейчас есть ситуации, когда это не верно.

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

Ну те же поля ввода и комбобоксы вполне могут ресайзится при изменении размера окна (а у них есть рамочки, градиенты и т. д.). С layout'ми кнопки тоже вполне могут это делать. А тулкит должен поддерживать возможность построения любых интерфейсов. Кнопка, занимающая всегда определённый процент окна, может пригодится в каких-то случаях. Да можно просто вспомнить про мониторы с разным DPI. Если все элементы интерфейса (включая кнопки, полосы прокрутки и т. д.) будут масштабироваться в векторном виде, то интрефейс будет выглядеть значительно приятнее. Если этого не делать вообще (захардкодить все размеры), то на HighDPI дисплее всё будет жутко мелкое, если делать как в винде (растровое масштабирование), то получается дикое мыло и в итоге на мониторе с низким DPI изображение качественнее, чем на HighDPI, чего быть не должно.

А кеширование изображений любой нормальный тулкит вполне себе применяет.

Ну те же поля ввода и комбобоксы вполне могут ресайзится при изменении размера окна (а у них есть рамочки, градиенты и т. д.). С layout'ми кнопки тоже вполне могут это делать. А тулкит должен поддерживать возможность построения любых интерфейсов. Кнопка, занимающая всегда определённый процент окна, может пригодится в каких-то случаях.

А кеширование изображений любой нормальный тулкит вполне себе применяет.