LINUX.ORG.RU

Solus отказывается от GTK

 , , ,


3

2

Один из лидеров проекта Solus Linux, Джошуа Стробл (Joshua Strobl), объявил о намерении отказаться от GTK при разработке как будущих версий Budgie, так и всей экосистемы приложений в Solus. В своем блоге он высказал ряд упреков в адрес текущего состояния и планов развития GTK, а также философии разработки GNOME.

По его словам, повсеместное насаждение Adwaita как единственно верной темы рабочего стола и попутное удаление части API для разного рода кастомизации добавило головной боли разработчикам, поддерживающим стек GNOME в дистрибутивах или интегрирующим в него свои приложения. Все предлагаемые варианты настройки внешнего вида приложений на базе GTK и сопутствующих библиотек отклоняются, а участники команды GNOME в ответ грубят в тикетах и соцсетях.

Жалуется Джошуа и на то, что выпущенный чуть менее года назад GTK 4 немного усложнил код для работы с виджетами, запретив прямое наследование. Но гораздо более важной проблемой ему видится упразднение API X11, в частности для получения конфигурации подключенных мониторов. Двигаясь в сторону полной поддержки Wayland, GNOME удалил функции опроса X-сервера, поручая разработчику писать собственные интерфейсы для обращения напрямую к X11 (либо к API других ОС, если приложение оказалось кроссплатформенным).

В то время как рабочая функциональность удаляется, многие известные ошибки в GNOME не исправляются месяцами и годами (в частности, автор приводит в пример ошибки с прокруткой в GtkListView и с переключением на другое окно при открытом выпающем списке в GtkPopover). При этом Джошуа описывает это в разрезе собственного опыта написания с использованием GTK своего аудиоплеера Koto.

Релиз GTK 4 не оправдал ожидания авторов Solus, надеявшихся на ряд обещаемых изменений в libhandy, которые в итоге так и не были добавлены. А дорожная карта к GTK 5 предрекает ещё большее закручивание гаек в части кастомизации и общий регресс как в UX, так и для использования библиотки в сторонних приложениях. Джошуа прямым текстом утверждает, что использование в разработке GTK 4 и выше — это выстрел себе в ногу.

По итогам этих размышлений лидеры проекта Solus приняли решение отказаться от использования GTK в Budgie и в целом минимизировать присутствие GNOME в своем пользовательском окружении, перейдя к выбору одного из следующих GUI-тулкитов:

  • EFL (библиотека в основе Enlightment Desktop);

  • Qt;

  • iced (кроссплатформенная GUI-библиотека для Rust).

В случае Qt разработчикам Solus не хочется писать код на C++, и к тому же смущает «коммерческая лицензия» Qt и неприятный осадок. iced находится в ранней стадии разработки и многие полезные вещи придется писать с нуля, а ресурсов для этого нет.

Остаётся EFL, который в итоге и был выбран. Постепенно планируется написать на EFL свои виджеты, а затем и основные десктопные приложения, либо адаптировать существующие, по возможности не связанные с GNOME.

Что касается дистрибутива, то версия с GNOME будет собираться в отдельный образ, и ей будет уделен минимум внимания, будет обеспечена лишь базовая работоспособность. В Budgie 11 не будет никаких зависимостей от GTK.

>>> Подробности

★★★★★

Проверено: hobbit ()
Последнее исправление: sudopacman (всего исправлений: 9)

Ответ на: комментарий от EXL

а когда запускаю что-то на GNOME под Wayland, то вижу либо это: https://gitlab.gnome.org/GNOME/mutter/uploads/b706e4893efd048fdb77e32c6f64ae36/Снимок_экрана_от_2017-12-16_11-04-00.png

А что не так? Я вижу 4 разных терминалов с абсолютно разным оформлением и медиаплеер. Мне сложно представить человека, которого 5 по-разному оформленных окон могут всерьёз расстроить. Ещё сложнее представить человека, который перестанет расстраиваться, если все эти окна обернуть в одинаковые рамки.

Но если предположить, что такие люди бывают, то я бы посоветовал обратить внимание на обои на этом скриншоте. Они однотонные и с одинаковым паттерном. И они окружают все окна. Точно так же как могли бы окружать SSD-рамки. Это должно решить все проблемы. Если одинаковый паттерн обоев не помогает примириться с разным обликом разных тулкитов, то SSD тоже не поможет.

Либо это: https://baat.z-lab.me/~exl_lab/screens/GNOME3_wayland_mpv_fuckup.png

Очень хорошая картинка, демонстрирующая весь дзен CSD-инициативы (и всю глупость её хейтеров). На этой картинке изображено окно MPV, с заголовком MPV и кнопочками MPV. Если человек способен как-то мириться с этими кнопочками, или даже наоборот, ему они нравятся своей брутальностью и минимализмом, то заголовок окна в том же стиле точно так же должен нравиться. Уродством наоборот является тот старый MPV, где вокруг окна хипсторский заголовок, а внутри, собственно MPV рисующий контролы пролетарским ЧБ. Ну а кому кнопки/заголовки такого типа не по вкусу, им сделаны форки под тулкиты или обёртки типа smplayer.

https://baat.z-lab.me/~exl_lab/screens/G3_Wayland_SDL2_Games.png

Некорректно написанная программа, ложно обещающая совместимость с вялендом. Под вялендом в принципе нельзя рассчитывать на наличие серверных декораций, поэтому программа должна рисовать рамку сама или уметь обходиться без неё.

В общем, трагедия в том, что у SSD есть одна единственная полезная фишка: если программа зависла, то SSD позволит переместить, минимизировать или нажать на кнопку закрытия. В остальном эта фича только создаёт проблемы. Разработчиков безтулкитных программ она заставляет писать и отлаживать 2 кодепаса. Дизайнеров тем для окон она заставляет делать окну вырвиглазный заголовок, для того чтоб он выглядел одинаково убого вне зависимости от того, поддерживает ли тулкит приложения ту же тему что и ДЕ или нет. Для сравнения: если в гном-терминале установить тёмную тему, а в гном-едиторе - дефолтную адвайту, то эти 2 окна будут смотреться одинаково красиво и рядом, и будучи запущенными под любым DE. Для пользователей SSD даёт потерю пространства окна на 3 кнопки и бесполезный текст. Для линупс-сообщества вцелом - препятствует принятию новых тулкитов, любая новая фигня будет приниматься с большим скрипом просто потому что из-за SSD пол-окна будет выглядеть неизвестно как, поэтому лучше взять старую добрую QT и надеяться, что авторы дистра позаботились о наличии совместимой темы для QT.

khrundel ★★★★
()
Ответ на: комментарий от R_He_Po6oT

Но там есть возможность изменить декорации определённому приложению, а не просто классу окон?

Так класс приложения можно сузить до окна. class/role/instance/name/program и т. д. Можно, в общем-то, спуститься до нужного окна. Но в IceWM поменять тему саму нельзя, можно кнопки управления окном убрать/отобразить. Не сделали такого целиком с темами. Видимо, никто не просил. Может, другие WM позволяют. По большому счету вполне можно предложить механизм через обмен properties у окон, чтобы приложение просило что-то поменять оконный менеджер, но таких стандартных договоренностей просто нет. Технически они возможны.

Ну а если приложение хочет свои декорации рисовать, то ему оконный менеджер типа IceWM может не мешать. Допустим, evince на gtk3 рисует свои декорации, IceWM рисует еще дополнительно свои. Вот IceWM конкретно и куча других менеджеров с правилами, а также через devilspie (наверное, так как не помню, можно ли декорации убрать, но, кажется, да), можно попросить по правилам у evince декорации WM не рисовать, а оставить декорации приложения. Но я вообще наоборот делаю: я подавляю CSD и прошу оставить декорации WM:

~/.config/gtk-3.0/settings.ini

[Settings]
gtk-decoration-layout = menu,appmenu

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

Zubok ★★★★★
()
Последнее исправление: Zubok (всего исправлений: 1)
Ответ на: комментарий от Shadow

частный случай

Существования обратного достаточно для доказательства ложности исходного утверждения.

Rootlexx ★★★★★
()
Ответ на: комментарий от R_He_Po6oT

Бред - это пользоваться светлыми приложениями в тёмном окружении и тёмными в светлом

🤦

Могу лишь пожелать вам всю жизнь редактировать фото и писать код в светлом окружении, или верстать документы в тёмном.

Rootlexx ★★★★★
()
Ответ на: комментарий от Zubok

Видимо, никто не просил

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

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

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

R_He_Po6oT ★★★★
()
Ответ на: комментарий от Rootlexx

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

меню файл нужен не для всех программ потому что не все программы работают с файлами и тем более не для всех окон и отсюда вывод - работа с файлами это не работа оконного менеджера

короче я тебе соболезную - лечи логику

anonymous
()
Ответ на: комментарий от R_He_Po6oT

Нет, то классы окон, это другое

Класс — это условно имя программы. Еще есть поле name, но его сама программа может менять, напрмер, вписать туда путь к открытому файлу. Т.е. это то, что отображается в тайтлбаре. Кастани xprop и увидишь.

BceM_IIpuBeT ★★☆☆☆
()
Ответ на: комментарий от Rootlexx

Неуслышал... Ты безнадёжный, или упёртый? Признать, что гном ничего не умеет, даже рисовать сторонние окна, это не стыдно, но это шажок к выздоровлению.

R_He_Po6oT ★★★★
()
Ответ на: комментарий от anonymous

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

https://ibb.co/F7tyST6

короче я тебе соболезную - лечи логику

Rootlexx ★★★★★
()
Ответ на: комментарий от Rootlexx

В Windows не встречал ни одного треда в котором бы спорили о том, кто должен и как отрисовывать окна.
Мда …

anonymous
()
Ответ на: комментарий от R_He_Po6oT

Неуслышал… Ты безнадёжный, или упёртый? Признать, что гном ничего не умеет, даже рисовать сторонние окна, это не стыдно, но это шажок к выздоровлению.

От попыток аргументировать перешли на личности и голословные заявления — вы явно побеждаете в споре.

Rootlexx ★★★★★
()
Ответ на: комментарий от Rootlexx

Не передёргивайте. Я показал, что оконный менеджер не обязан отрисовывать заголовки окон, чтобы являться оконным менеджером.

Mutter в GNOME является менеджером окон для широкого круга пользователей, который отрисовывает заголовки по умолчанию в приложениях нам том же сеансе X11. Почему он этого не делает на Wayland-сеансе у тех же самых приложений? Здесь явно видна неконсистенция и регресс.

И при этом не соответствует теме запущенного в этом же окне, к которому он рисует заголовок

О какой теме идёт речь? Системной теме он соответствует. А системная тема соответствует теме виджетов. В GNOME 3 ситуация с различными несоответствиями заголовков окон куда хуже. Скриншот этот я замучался уже постить.

а также не позволяет интегрировать в него хоть что-то полезное.

В идеальном мире приложения которые требуют CSD явно должны об этом просить оконный менеджер. Тогда он просто отключит стоковый заголовок и всё. Причина-то в том, что далеко не каждому приложению нужен CSD. Нафига он, например, казуальной игрушке на SDL2? Почему разработчики GNOME внезапно вдруг решили что все разработчики тулкитов сделают у себя CSD под их хотелку? Этого не произошло. И в итоге разработчики GNOME сами стали вынуждены пилить костыли вроде QGnomePlatform и libdecor и решать проблему, которая вытекла из их ПОЛИТИЧЕСКОГО решения не поддерживать xdg-decorations или любой другой способ отображения заголовков и рамок окон в системном стиле GNOME.

Т.е. разработчики приложения нарисовали декорации, которые «работают и выглядят как говно», но виноват в этом опять GNOME? Маразм как он есть.

Разработчики приложения никоим образом не обязаны следить за пертурбациями в проектах GNOME или KDE. Сегодня у них квадратные и узкие заголовки окон, а завтра – широкие и округлые. С какой стати разработчики прикладных приложений должны бегать за дизайнерскими решениями Adwaita и Breeze и криво копировать их в свои приложения?

В том, что Wayland встретил на пути преграду в виде такого вот идиотского политического решения по заголовкам окон виноват действительно GNOME и его разработчики. В том, что Mutter не обеспечивает мне должный UX/UI на Wayland-сеансе при использовании приложений использующих тулкит отличный от GTK+, виноваты GNOME-разработчики. Просто потому что в X11 такой проблемы у них нет.

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

Впрочем, судя по коммиту в SDL всё постепенно движется в правильном направлении.

Постепенно. Вот уже 6+ лет они не могут решить проблему, которую создали на ровном месте.

EXL ★★★★★
()
Ответ на: комментарий от Rootlexx

Оп, пошли виляния. Долго ты этот скрин делал? У меня оно меньше секунды висит.

BceM_IIpuBeT ★★☆☆☆
()

Это те дегенераты, которые против Столлмана втроём топили? Поделом, пусть их говнопроект утонет.

Hertz ★★★★★
()
Ответ на: комментарий от anonymous

Расскажешь игорям про то что им заголовка не хватает? А ещё панелям всяким, которые, внезапно, даже в винде отдельные графические программы.

peregrine ★★★★★
()
Ответ на: комментарий от anonymous

совпадение? не думаю!

А куда им спешить?
Если они за месяц наведут порядок, то их всех уволят.
А так они НУЖНЫЕ ЛЮДИ …

anonymous
()
Ответ на: комментарий от peregrine

Расскажешь игорям про то что им заголовка не хватает?

В нормальных средах все работает.

Хочешь с рамочками: https://i.imgur.com/sSlFZnx.jpg

Хочешь без рамочек: https://i.imgur.com/0cNdnL8.jpg

В НОРМАЛЬНЫХ средах нету НИКАКОЙ проблемы.

BceM_IIpuBeT ★★☆☆☆
()
Ответ на: комментарий от anonymous

Какое окружение рабочего стола вы считаете ХУДШИМ?

Говорят, голоса за (или против) gnome накручивают.

anonymous
()
Ответ на: комментарий от R_He_Po6oT

В Гноме плохо всё. Вот, ровно всё.

Если они в этих вопросах не БУМ БУМ, то почитали бы как в Windows эти вопросы решены …

anonymous
()
Ответ на: комментарий от EXL

Mutter в GNOME является менеджером окон для широкого круга пользователей, который отрисовывает заголовки по умолчанию в приложениях нам том же сеансе X11. Почему он этого не делает на Wayland-сеансе у тех же самых приложений?

Потому что в отличие от Wayland там нет необходимости самим отрисовывать заголовки, если они нужны.

Плюс обратная совместимость: приложения, написанные под условия старого API, должны продолжать работать, как раньше. На новый интерфейс это не распространяется.

А системная тема соответствует теме виджетов.

Вам ещё раз показать Blender, Shotcut и прочие? Или Google Chrome продемонстрировать?

Причина-то в том, что далеко не каждому приложению нужен CSD. Нафига он, например, казуальной игрушке на SDL2?

Ну так пускай рисует стандартный полупустой заголовок.

Почему разработчики GNOME внезапно вдруг решили что все разработчики тулкитов сделают у себя CSD под их хотелку?

Вижу, до вас никак не доходит, что разработчики тулкитов обязаны это делать вне зависимости от существования GNOME. Просто потому что xdg-decoration является лишь опциональным расширением протокола.

Вот если станет обязательным и попадёт в core — тогда отсутствие его поддержки будет адекватной претензией к любому композитору. Но до тех пор — «чините приложения».

Разработчики приложения никоим образом не обязаны следить за пертурбациями в проектах GNOME или KDE. Сегодня у них квадратные и узкие заголовки окон, а завтра – широкие и округлые. С какой стати разработчики прикладных приложений должны бегать за дизайнерскими решениями Adwaita и Breeze и криво копировать их в свои приложения?

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

В том, что Mutter не обеспечивает мне должный UX/UI на Wayland-сеансе при использовании приложений использующих тулкит отличный от GTK+, виноваты GNOME-разработчики. Просто потому что в X11 такой проблемы у них нет.

Потому что X11 ≠ Wayland, и требования у них к клиентским приложениям разные.

Вижу, что вынужден повторять одно и то же по десятому кругу, а до вас эта простейшая мысль всё никак не дойдёт, увы.

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

Не используйте связку GNOME + Wayland. Используйте то окружение, которое более соответствует вашим чаяниям. Спасибо.

Rootlexx ★★★★★
()
Ответ на: комментарий от peregrine

очень хорошо верстаются кстати

Проблема в том, что печататься они будут совсем не светлыми чернилами на тёмной бумаге.

Rootlexx ★★★★★
()
Ответ на: комментарий от R_He_Po6oT

Продолжай игнорировать суть и выдумывать отмазки.

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

У себя вы можете пользоваться чем угодно как угодно, мне без разницы — но я оставляю такое же право и за собой.

Rootlexx ★★★★★
()
Ответ на: комментарий от Rootlexx

Суть в том, что НЕ в Гноме МОЖНО решить твою (пусть и надуманную по моему мнению) проблему. В этом суть, надо переписывать не весь мир, а только Гном.

R_He_Po6oT ★★★★
()
Ответ на: комментарий от BceM_IIpuBeT

Где же тень у этого окна без декораций? Ведь в KDE всё так единообразно и консистентно!

Могу ещё Google Chrome без системных декораций показать.

Rootlexx ★★★★★
()
Ответ на: комментарий от Rootlexx

Не используйте связку GNOME + Wayland.

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

anonymous
()
Ответ на: комментарий от peregrine

А т.е. ты вообще не видел тёмных тем? С виндовса поди старого? Времён ХП-шки? Понимаю…

Какое отношение это имеет к вёрстке документа в тёмной теме?

Rootlexx ★★★★★
()
Ответ на: комментарий от R_He_Po6oT

Суть в том, что НЕ в Гноме МОЖНО решить твою (пусть и надуманную по моему мнению) проблему

Ещё раз: в Wayland приложения обязаны уметь отрисовывать декорации на стороне клиента, если они им вообще нужны. Точка.

Rootlexx ★★★★★
()
Ответ на: комментарий от anonymous

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

Отличный ответ пользователям, которые заявляют, что окружение А им не нравится, а окружение Б нравится, — «используйте окружение Б».

Rootlexx ★★★★★
()
Ответ на: комментарий от Rootlexx

Ещё раз: в Wayland приложения обязаны уметь отрисовывать декорации на стороне клиента, если они им вообще нужны. Точка.

Получается в Linux нет единой оконной системы?

anonymous
()
Ответ на: комментарий от khrundel

О, у нас тут Хрюндель в сраче про декорации объявился. Помнится мы с тобой уже года три-четыре назад спорили на тему SSD и CSD в Wayland-окружениях, вроде GNOME.

Я тогда, когда ещё не было библиотеки libdecor.so, заявил следующее:

Разработчики GNOME 3 должны сделать так, чтобы SDL2, GLFM, GLFW и пр. приложения брали заголовок окна из написанной самими гномовцами libsimplewindow.so, которая отвечает всем текущим дизайнерским потребностям DE и может обновляться независимо от библиотек, которые её используют.

На что ты разродился простынями вроде:

Зачем это всё? Зачем библиотеке обновляться независимо? А если я программу на java пишу, мне тоже эту либу цеплять? Пусть берут ту либу, которую хотят. Кому-то попроще, кому-то покрасивее и чтоб системную тему подхватывало.

Почему они не должны запихивать в SDL2, GLFM, GLFW и прочее весь функционал по работе с вейландом, а рисование заголовков должны?

EXL: Потому что GNOME’овцы сами должны поддерживать свои заголовки в соответствии со своим HIG’ом.

Кому должны? Зачем заголовок с гномовским HIGом, если само приложение этому хигу не следует? Да и невозможно это.

Ситуация сегодня:

Разработчики GNOME представили библиотеку libdecor с HIG’ом, которую уже начал использовать SDL2. Интересно (нет) что ты там напишешь на этот раз.

Очень хорошая картинка, демонстрирующая весь дзен CSD-инициативы (и всю глупость её хейтеров). На этой картинке изображено окно MPV, с заголовком MPV и кнопочками MPV

Да-да, хотел бы я тебе уменьшить все кнопочки в твоём DE в заголовках окна до размера блох на кошке и понаблюдать с недельку как ты их «выщипываешь» курсором.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от Rootlexx

Тебя никто не спрашивает почему ты пользуешься гномом, тебя спрашивают почему твой ничего не умеющий, гном, который занимает меньшую долю, чем даже одно КДЕ (и по моему, даже меньше чем ХФЦЕ), ломает весь опенсорсный десктоп и ведёт себя как пьяный медведь, что от него даже разрабы как от огня бегут?

R_He_Po6oT ★★★★
()
Ответ на: комментарий от Rootlexx

Если Гном своим оконным менеджером берётся регулировать окнами, то и декорации им тоже должен, иначе нафиг он вообще нужен? Точка.

R_He_Po6oT ★★★★
()
Ответ на: комментарий от Rootlexx

Потому что X11 ≠ Wayland, и требования у них к клиентским приложениям разные.

https://blog.martin-graesslin.com/blog/2013/02/client-side-window-decorations-and-wayland/:

Nothing in the Wayland protocol requires Client Side Decorations or forbids Server Side Decorations. And that’s not surprising as it just should not matter to a protocol. The same is true for the X11 protocol, there is nothing said about window decorations. Just on X11 people realized that server side decorations are the better choice, but still there are applications doing client side

Сначала на X11 все использовали SSD. Потом гномоделы внедрили у себя везде CSD, устроив в десктопном линуксе зоопарк. А с переходом на Wayland они отказались добавлять поддержку SSD. Их об этом, просили, но они сказали, что в реализовать поддержку SSD в Mutter будет слишком сложно, и поэтому остальные разработчики должны переписывать свои приложения. Прям как NVIDIA с EGLStreams.

Ещё раз: были приложения, которые годами работали с SSD под X11. Потом их портировали на Wayland, и там они тоже работают с SSD — везде, кроме гнома, разработчики которого требуют от всех адаптироваться под CSD, потому что они не осилили реализовать поддержку SSD в гномощели (и потому что им лично CSD больше нравится).

Все разговоры про то, что CSD якобы стандарт под Wayland — демагогия в попытке оправдать некомпетентность и зловредность гномоделов, к сути никакого отношения не имеющая.

sudopacman ★★★★★
()
Последнее исправление: sudopacman (всего исправлений: 1)
Ответ на: комментарий от khrundel

SSD нужен как минимум для тайловых WM, в которых гномовские HeaderBar'ы занимают нереально много места и в принципе бесполезны. Но проблема в том, что сама сущность CSD в Linux абсолютно никак не стандартизирована, у каждого свои костыли. В Гномовских прогах - это неотключаемый заголовок

Sunderland93 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.