Я давно откладывал эту тему, но вот вышла эта новость, и, видимо, пора:
https://www.opennet.ru/opennews/art.shtml?num=56587
"Отмечается, что для полноценной работы приложений на базе SDL в Wayland требуется наличие библиотеки #libdecor для декорирования окон на стороне клиента."
libdecor - это леденящий душу пиздец.
Очень хорошо со стеком #glib /gtk я познакомился под НГ, когда собирал себе браузер Epiphany, на основе WebKitGTK(*).
* Он написан на диалекте С от GNU. Это очень странная объектная система, которая позволяет конструировать классы на лету, и несщадно тормозит, потому что минимум 2 уровня косвенности.
* Он жрет много памяти. Потому что любой объект в куче, там нет оптимизации любой нормальной VM, позволяющей создавать большинство объектов на стеке.
* Там есть система пропертей, которая реализована посредством линейного сравнения поступившего имени метода со всеми известными значениями, потому что хеш-таблиц в С не завезли.
* Он косой и кривой - я заметил, что браузер всегда мерцает(1 кадр - белый фон, второй - реальная картинка(видос записывать лень)). Бугага, зато девелоперы пишут победные статьи - https://blogs.igalia.com/carlosgc/2017/02/10/accelerated-compositing-in-webkitgtk-2-14-4/. Ремарка - плохие девелоперы у Igalia, не у WebKit.
В процессе исследования это проблемы я пришел к следующему интересному выводу: динамической линковкой в мире OSS решают две проблемы:
* Кто-то с кем-то не договорился. #fontconfig
* Круговые зависимости.
Сегодня про первую проблему :) #GNOME #SSD
Вот такой феерический тред - https://gitlab.gnome.org/GNOME/mutter/-/issues/217. Обязательно его прочитайте! Краткое содержание - все упрашивают разработчиков Gnome добавить поддержку server side decorations, а они отказываются, мотивируя тем:
* Что могут(Wayland не требует поддержки SSD).
* Что их собственный композитор не зависит и не должен зависеть от GTK. Дебилы, у меня нет других слов.
И, тем самым, не-GTK приложения должны в себя влинковывать GTK, чтобы не выглядеть в Gnome чужеродно. Чувствуете логику, да? То есть, не 1 гномовский композитор должен зависеть от их платформенной библиотеки, а каждое приложение на QT должно зависеть от чужой платформенной библиотеки.
Короче, TL;DR - они не договорились, и появилась библиотека libdecor, которая должна в runtime загрузить в себя плагин, который загрузит GTK в QT приложение, запустит в отдельном event loop GTK, и будет отрисовывать клиенсткие декорации.
Я думаю, последствия такого леденящего душу пиздеца очевидны - надежность и так ненадежного кода падает в разы, потребление памяти растет, сложность растет, у клиентов все глючит, потому что библиотека не может найти сраный плагин(это вообще такая особенность плагинов в мире OSS), и потому что определение того, под каким DE мы запущены, глючит.
И вот, теперь безвинные приложения на SDL будут загружать это УГ, и рисовать им декорации.
Я после этого треда очень сильно поменял свое отношение к этим упырям из Gnome, они реально негодяи. Считают, что GTK - это платформенный тулкит, и все должны под него подстраиваться. С его-то проблемами.
* Почему WebKIT? Мне показалось, что его проще всего собрать, потому что меньше мудохаться с вендорингом. Я ошибался, но это уже другая история.
https://www.opennet.ru/opennews/art.shtml?num=56587
"Отмечается, что для полноценной работы приложений на базе SDL в Wayland требуется наличие библиотеки #libdecor для декорирования окон на стороне клиента."
libdecor - это леденящий душу пиздец.
Очень хорошо со стеком #glib /gtk я познакомился под НГ, когда собирал себе браузер Epiphany, на основе WebKitGTK(*).
* Он написан на диалекте С от GNU. Это очень странная объектная система, которая позволяет конструировать классы на лету, и несщадно тормозит, потому что минимум 2 уровня косвенности.
* Он жрет много памяти. Потому что любой объект в куче, там нет оптимизации любой нормальной VM, позволяющей создавать большинство объектов на стеке.
* Там есть система пропертей, которая реализована посредством линейного сравнения поступившего имени метода со всеми известными значениями, потому что хеш-таблиц в С не завезли.
* Он косой и кривой - я заметил, что браузер всегда мерцает(1 кадр - белый фон, второй - реальная картинка(видос записывать лень)). Бугага, зато девелоперы пишут победные статьи - https://blogs.igalia.com/carlosgc/2017/02/10/accelerated-compositing-in-webkitgtk-2-14-4/. Ремарка - плохие девелоперы у Igalia, не у WebKit.
В процессе исследования это проблемы я пришел к следующему интересному выводу: динамической линковкой в мире OSS решают две проблемы:
* Кто-то с кем-то не договорился. #fontconfig
* Круговые зависимости.
Сегодня про первую проблему :) #GNOME #SSD
Вот такой феерический тред - https://gitlab.gnome.org/GNOME/mutter/-/issues/217. Обязательно его прочитайте! Краткое содержание - все упрашивают разработчиков Gnome добавить поддержку server side decorations, а они отказываются, мотивируя тем:
* Что могут(Wayland не требует поддержки SSD).
* Что их собственный композитор не зависит и не должен зависеть от GTK. Дебилы, у меня нет других слов.
И, тем самым, не-GTK приложения должны в себя влинковывать GTK, чтобы не выглядеть в Gnome чужеродно. Чувствуете логику, да? То есть, не 1 гномовский композитор должен зависеть от их платформенной библиотеки, а каждое приложение на QT должно зависеть от чужой платформенной библиотеки.
Короче, TL;DR - они не договорились, и появилась библиотека libdecor, которая должна в runtime загрузить в себя плагин, который загрузит GTK в QT приложение, запустит в отдельном event loop GTK, и будет отрисовывать клиенсткие декорации.
Я думаю, последствия такого леденящего душу пиздеца очевидны - надежность и так ненадежного кода падает в разы, потребление памяти растет, сложность растет, у клиентов все глючит, потому что библиотека не может найти сраный плагин(это вообще такая особенность плагинов в мире OSS), и потому что определение того, под каким DE мы запущены, глючит.
И вот, теперь безвинные приложения на SDL будут загружать это УГ, и рисовать им декорации.
Я после этого треда очень сильно поменял свое отношение к этим упырям из Gnome, они реально негодяи. Считают, что GTK - это платформенный тулкит, и все должны под него подстраиваться. С его-то проблемами.
* Почему WebKIT? Мне показалось, что его проще всего собрать, потому что меньше мудохаться с вендорингом. Я ошибался, но это уже другая история.
www.opennet.ru
Мультимедийная библиотека SDL переходит на использование Wayland по умолчанию
В кодовую базу библиотеки SDL (Simple DirectMedia Layer) принято изменение по умолчанию активирующее работу на базе протокола Wayland в окружениях, предоставляющих одновременную поддержку Wayland и X11. Ранее в Wayland-окружениях с компонентом XWayland по…
commit -m "better"
Я давно откладывал эту тему, но вот вышла эта новость, и, видимо, пора: https://www.opennet.ru/opennews/art.shtml?num=56587 "Отмечается, что для полноценной работы приложений на базе SDL в Wayland требуется наличие библиотеки #libdecor для декорирования…
#GNOME #gtk #ssd
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6161
Продолжение темы про server side decorations, жирно, годно.
На этот раз господа из gtk прямым текстом говорят, что wayland - им не указ:
"There is no debate. And this is not a standard. It is an experimental protocol that somebody slapped the xdg name on and merged into the wayland repos. It is not implemented by anybody except sway and kwin"
И ответ:
"Please refrain from making fun of the Wayland community this way. We've worked very hard to reach a consensus among all wayland-protocols members, and it feels like you're dismissing this work"
Тут вот активно форсят тему про планирующийся бой Маска и Цукерберга, а я вот, конечно, хотел бы посмотреть, как подерутся Simon Ser и Clasen, например.
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6161
Продолжение темы про server side decorations, жирно, годно.
На этот раз господа из gtk прямым текстом говорят, что wayland - им не указ:
"There is no debate. And this is not a standard. It is an experimental protocol that somebody slapped the xdg name on and merged into the wayland repos. It is not implemented by anybody except sway and kwin"
И ответ:
"Please refrain from making fun of the Wayland community this way. We've worked very hard to reach a consensus among all wayland-protocols members, and it feels like you're dismissing this work"
Тут вот активно форсят тему про планирующийся бой Маска и Цукерберга, а я вот, конечно, хотел бы посмотреть, как подерутся Simon Ser и Clasen, например.
GitLab
wayland: Update to xdg-decoration protocol (!6161) · Merge requests · GNOME / gtk · GitLab
Updated version of !2191; as such, I've copied basically everything,...
🔥10🐳2
commit -m "better"
Вот такой феерический тред - https://gitlab.gnome.org/GNOME/mutter/-/issues/217. Обязательно его прочитайте! Краткое содержание - все упрашивают разработчиков Gnome добавить поддержку server side decorations, а они отказываются, мотивируя тем:
https://www.phoronix.com/news/GNOME-Mutter-Cursor-Shape
Большой день - #GNOME добавили поддержку server side cursor. О боже, да, они разрешили, что какие-то пиксели над их бесценным приложением будет рисовать кто-то другой!!!
Не server side decorations (#SSD), но и то хлеб.
Ситуация, когда каждое приложение должно указывать, какой сейчас над ним курсор (в виде картинки) - это, конечно, жесть.
Большой день - #GNOME добавили поддержку server side cursor. О боже, да, они разрешили, что какие-то пиксели над их бесценным приложением будет рисовать кто-то другой!!!
Не server side decorations (#SSD), но и то хлеб.
Ситуация, когда каждое приложение должно указывать, какой сейчас над ним курсор (в виде картинки) - это, конечно, жесть.
Phoronix
GNOME's Mutter Now Supports The Wayland Cursor Shape Protocol
Racing toward the GNOME 48 finish line, developers have remained busy squeezing some remaining bits into place for this big open-source desktop release.
😁15🐳4👍2