GTK 4 вышел

GTK 4 вышел

Мало нам было «короны»…

Ща начнётся.

flatpak run org.gtk.Demo4

Крашнуло мне Wayland (Hikari, wlroots).

Что поломали?

Отличные новости

GTK 4.0 ≠ GTK 4?

А я не могу скачать. Таймаут.

Это же не кеды.

Ненужно

Хвалёный вяленный

Скачалось. Ничего не крашнулось - Gnome 3 на Wayland.

Правильно говорить «что вырезали?». Или «кого захарассили?», «но это уже совсем другая история» ©

Хотя я сходу не нашёл ничего такого, видимо в кои-то веки разработчики решили именно что добавить функционал. И выглядят демки примерно так же, как GTK3-приложения.

That does not mean GTK 3 is dead – we will continue to support and update it for the foreseeable future

Та хоспаде боже, ни себе ни людям. Оставили-бы GTK3 уже в покое, блин. Может хоть начать пользоваться можно будет без риска что в новом релизе что-то опять сломают.

С какого-то китайского сервера скачало, что настораживает:

https://chuangtzu.ftp.acc.umu.se/pub/GNOME/sources/gtk/4.0/gtk-4.0.0.tar.xz

Крашнуло мне Wayland (Hikari, wlroots).

Там кто-то говорил про безопасность Wayland? А он вообще падает, не удивлюсь что можно получить доступ к памяти Wayland сервера из клиента.

.se это Швеция так-то

Университет Умео

Меня поддомен chuangtzu смущает.

Файловый диалог нормальный запилили хоть?

Да, гтк2 прекратят поддерживать

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

Если темы в нем не сломали, то действительно GTK 4.0 ≠ GTK 4

А поддомен torvalds бы не смутил?

Не дождётесь!

По версиям зависимостей GTK4 ни разу не светит ни openSUSE Leap 15, ни 7-й Магейе. Только openSUSE Leap 16 (которая, по ходу, выйдет в 2022-м году) и Магейе 8 (которая выйдет в следующем 2021-м году). А вот в openSUSE Tumbleweed GTK4 вполне уже есть (хоть пока и бета версии). Как и в котле Магейи.

CentOS, ALT, Rosa, Debian 10,... и т.д. тоже пока что в пролёте.

Хотя я сходу не нашёл ничего такого, видимо в кои-то веки разработчики решили именно что добавить функционал

• GtkMenu выкинули, но кое-какая замена есть
• GtkMenuImage, замену ручками
• GtkToolbar, замену ручками
• GtkStatusIcon выкинули, замену надо искать в других проектах
• gtk_dialog_run(), замена есть
• GtkContainer убрали, теперь надо к каждому виджету-контейнеру своё API запоминать. Возвращаемся во время без ООП.

Ну, и выкинули самое главное: gtk_main() и gtk_main_quit().

И выглядят демки примерно так же, как GTK3-приложения.

За исключением того, что между пунктами слева в gtk4-demo просто огромное пространство. Вместо привычного списка, где сразу видно почти всё и легко ориентироваться. Но, может, они на их HiDPI мониторах уже и не замечают, что они творят.

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

теперь надо к каждому виджету-контейнеру своё API запоминать.

Вот только на половине виджетов стандартный add работал или через ****, или вообще не имел смысла, и потому попросту не использовался.

Ну, и выкинули самое главное

…Который deprecated уже давным-давно, и на замену которому есть gtk_application.

Меня радует, что композитор, который пишет один человек в свое свободное время вы экстраполируете на все композиторы.

Там уже успели сделать зоопарк композиторов и ни одного нормального:

• mutter: нет SSD и других протоколов, прибит к убогому GNOME.
• wlroots: нет классического оконного менеджера не для инопланетян, падает как выяснили в этом треде.
• Weston: референсная реализация не пригодная к использованию.
• kwin: не работает, много багов.

Не вижу смысла дожидаться пока что-либо из этого доведут до ума, лучше всё это вместе с протоколом Wayland отправить на помойку и продолжать пользоваться проверенным и рабочим X.Org. Если за 10 лет не смогли сделать ни одной нормальной реализации, то технология мертворождённая. Энтузиасты за 2 года с нуля пишут ОС со своим ядром, композитором, тулкитом и даже браузером. Подозреваю что там протокол композитора сделан лучше, чем в Wayland.

падает как выяснили в этом треде.

Как выяснили в этом треде, падает hikari. На (как минимум) sway демка нормально работает. Как sway, так и hikari используют wlroots, ergo проблема в hikari, а не в wlroots.

Подозреваю что там протокол композитора сделан лучше, чем в Wayland.

Советую почитать протокол перед тем, как что-то подозревать.

лучше всё это вместе с протоколом Wayland отправить на помойку и продолжать пользоваться проверенным и рабочим X.Org

Зачем думать, тут трясти надо! (c)

Энтузиасты за 2 года с нуля пишут ОС

Я рад за энтузиастов. Хорошо быть энтузиастом, когда тебя не стесняют строгие требования и легаси код, в который нужно встроить поддержку wayland, не выкидывая x11, и при этом ничего не поломать.

Советую почитать протокол перед тем, как что-то подозревать.

Задания абсолютной позиции окон там нет, а в SerenityOS есть. SSD в SerenityOS тоже есть. И полноценное управление окнами в отличии от Wayland тоже есть.

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

Проще все тулкиты и Wine на Serenity портировать, чем на Wayland. Там есть всё необходимое, а не паранойя как в Wayland. Qt легко портируется, нужно только написать platform plugins, для Haiku написали. GTK 3+ тоже несложно портируется. Жёсткой привязки к X11 нигде нет.

Вообще Cerenity - это шах и мат неосиляторам из Wayland. Им даже поддержка корпораций не помогает.

или вообще не имел смысла, и потому попросту не использовался.

Возможно, наследование в ООП нужно было бы заменить чем-то более подходящим, чтобы потом не надо было лепить delete.

Задания абсолютной позиции окон там нет, а в SerenityOS есть. SSD в SerenityOS тоже есть.

То есть вместо модульного протокола опять монолит сделали, а вы выдаете это за плюс?

Проще все тулкиты и Wine на Serenity портировать, чем на Wayland.

Конечно проще, только Serenity никому не нужна и ничего нового пользователям не предоставляет.

То есть вместо модульного протокола опять монолит сделали, а вы выдаете это за плюс?

Да, монолитный протокол - это плюс. Лучше рассчитывать, что в протоколе есть всё нужное чем писать тонны проверок и boilerplate кода который всё равно не будет работать как надо во всех комбинациях реализованных протоколов.

Serenity никому не нужна

Посмотрим. Пока даже 10 лет не прошло. При удачном раскладе претендует на полное закапывание десктопного Линукса вместе с ядром и тулкитами.

Здесь можно было бы либо налепить иерархию вида

             Container
              /     \
ContainerAddable   (остальные контейнеры)
  | | |
(контейнеры, где
 add имеет смысл)

или писать трейты, под что объектная модель Gtk не заточена.

Лучше рассчитывать, что в протоколе есть всё нужное чем писать тонны проверок

Не нужно никаких тонн проверок, нужна проверка наличия используемых расширений. Есть расширение – есть фичи.

всё равно не будет работать как надо

Зачем стараться, можно сразу все криво сделать и сидеть довольному.

Есть расширение – есть фичи.

А если нет - падать? Замечательная архитектура… В монолитном протоколе всё просто железно работает.

О, вслед за 6 культями. Предвкушаю боль и страдания.

А если нет - падать? Замечательная архитектура…

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

Зачем стараться, можно сразу все криво сделать и сидеть довольному.

Зачем страдать если можно просто использовать монолитный протокол? Никакого смысла в расширяемом протоколе нет, управление окнами ещё во времена Windows 1.0 спроектировали и с тех пор ничего существенного не менялось.

либо завершать работу с соответствующей ошибкой и ненулевым кодом возврата.

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

управление окнами ещё во времена Windows 1.0 спроектировали и с тех пор ничего существенного не менялось.

Я уже устал вам объяснять, почему мало того, что поменялось, так еще и модель, используемая в т.ч. Windows 1.0 изначально крива и убога, так как ставит машину выше пользователя.

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

Вы демагог.

То есть вместо модульного протокола опять монолит сделали, а вы выдаете это за плюс?

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

Я уже устал вам объяснять

Мнение пользователей тайловых WM меня особо не интересует. Хотя Windows 1.0 была тайловая, так что всё возможно.

так как ставит машину выше пользователя

Какие-то странные фантазии. Никто никого выше не ставит. В протоколах и API такие понятия не используются.

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

Мнение пользователей тайловых WM меня особо не интересует.

А у меня и не тайловый WM. Как из моих слов следует тайловость – неясно.

В протоколах и API такие понятия не используются.

Это не вординг протокола или API, это их суть и смысл.

Как из моих слов следует тайловость – неясно.

Для нетайловых WM модель Windows прекрасно ложится на любую оконную систему и реализована везде, кроме Wayland.

А оно на иксах всё ещё работает, или уже только на Вейлянде?

x11-backend, win32-backend, broadway-backend, wayland-backend and quartz-backend

Enable specific backends for GDK. If none of these options are given, the Wayland backend will be enabled by default, if the platform is Linux; the X11 backend will also be enabled by default, unless the platform is Windows, in which case the default is win32, or the platform is macOS, in which case the default is quartz. If any backend is explicitly enabled or disabled, no other platform will be enabled automatically. 

https://developer.gnome.org/gtk4/stable/extra-configuration-options.html#id-1.9.2.6.7