Разработчики обсуждают возможность прекращения поддержки X11 в GTK 5

по прекращению поддержки X11

xwayland в помощь этим товарищам

Это протестное действие, не важно куда я потрачу свои деньги, важно куда я их не потрачу.

Это не протестное действие, это какой-то жалкий юношеский максимализм и фанатизм.

В современном мире чем абсурднее заявление, тем оно действеннее. Даже Photoshop был заявлен исключительно для контраста, потому что нередко GIMP хотят видеть именно таким.

сам xcb является недокументированным куском кала

Жизнь — боль!

чтобы написать что-то на нём нужно ковырять исходники backend’ов существующих проектов

А код самого xcb посмотреть не судьба? Учитывая что почти весь софт, пишущийся для Linux, имеет отвратительную документацию (если вообще имеет), должны уже ковырять исходники. Тем более так любимая линуксоидами GPL именно этого и добивалась.

Ну помимо Gimp Gtk еще использует хромой, лиса м птицей, либреофис. Причем лисоводы объявили что не собираются переходить на Gtk4 ибо не видят в этом никаких плюсов.

То есть пока складывается ситуация что гном с ненужной кучей говна переходит на все более и более дерьмовые версии тулкита, а годнота остается на стабильном классическом варианте. Учитывая что у того же гимпа портирование на Gtk3 заняло уже несколько лет и так и не свершилось - ожидать что он будет переведен на вяленый gtk5 не стоит. А вот с либреофисом вопрос интересный - они вроде как под gtk4 понемногу портируются, и могут дропнуть поддержку gtk3 со временем.

Причем лисоводы объявили что не собираются переходить на Gtk4 ибо не видят в этом никаких плюсов.

Ну так работать-то оно всё равно будет. EOL GTK3 пока не объявляли. GTK2 GIMP вполне себе работает в самом распоследнем Wayland. Тут кто-то даже софт на GTK1 собирал ради интереса на новой ОСи и он работал (вроде-бы i-rinat это был, но я не помню).

Так что, если каких-то серьёзных проблем не возникает, зачем им лишняя работа.

у того же гимпа портирование на Gtk3 заняло уже несколько лет и так и не свершилось

Выше писал.

ожидать что он будет переведен на вяленый gtk5 не стоит

GTK5 ещё даже в проекте нет. Обсуждение чисто на перспективу.

gimp на третий gtk ещё не перешёл.

Можно подумать, не было ни одного пререлиза гимпа на гтк3.

Можно подумать, это единственное приложение на гтк.

Можно подумать, гимп нужен всем.

Можно подумать, большинство пользователей гимпа вообще пользуются линуксом, а не виндой.

Мигающим ЧЁРНЫМ прямоугольниками окна за годы только немного присыпали песочком, чтобы не так заметно было. Вместо чёрного там теперь прозрачное поле внутри рамки окна, которое потом заполняется содержимым. Разработчикам GTK 3 на это плевать по большому счёту.

Мне кажется, что это такая диверсия, чтобы протолкнуть CSD окна, потому что с ними такого нет. Но это правда, что в GTK2 все нормально работает, даже в Qt и в дефолтных иксовых приложениях, вроде xterm. После вышенаписанного можно даже не обсуждать всё остальное, GTK - днище и в этом виноваты разработчики GTK.

Учитывая что у того же гимпа портирование на Gtk3 заняло уже несколько лет и так и не свершилось - ожидать что он будет переведен на вяленый gtk5 не стоит.

Базовое портирование гимпа на гтк заняло около недели 12 лет назад. Этот порт уже тогда запускался и кривенько, но работал.

Несколько лет с момента релиза 2.10, про которые ты говоришь — это не столько портирование, сколько рефакторинг остального кода, дописывание фич и переписывание кода, который отвечает за работу с цветовыми пространствами.

Как пример рефакторинга — возможность выбирать несколько слоёв сразу и чего-нибудь с ними делать. В гимпе была прибита гвоздями концепция «может быть выделен только один элемент treeview». Получилось нормально это переписать только с третьей попытки, причём не самым безнадёжным программистом.

Парни просто заморочились сделать чистый, опрятный порт без использования deprecated-фич и с минимумом костылей в остальной части кода. Релиза нет по сути потому, что начата и не завершена работа сразу в нескольких направлениях. Порт на гтк3 – лишь одно из них.

Причем лисоводы объявили что не собираются переходить на Gtk4 ибо не видят в этом никаких плюсов.

В GTK4 даже не субпиксельного рендеринга шрифтов. Так что готовьтесь к лютому ШГ если встретится хотя бы одно GTK4 приложение. Также попрощайтесь к кастомными и dock виджетами. В GTK4 их не будет. А так как Wayland ещё не генерирует события передвижения, попрощайтесь с ними в GTK4 во всех GtkWidget объектах, и с захватом (grab) тоже попрощайтесь т.к gdk_device_grab больше нету. Использовать эти фичи в GTK4 вы не должны (C).

Плюсом ещё и цветовыми пространствами занялись. Хотя, как я понял и не собирались до релиза, но люди внезапно нашлись и занялись. Что тоже релиз ест-но оттянет, как я понимаю.

CMYK в его реализации для 3.0 релиз не оттянет по той простой причине, что изменения атомарные и вливаются сразу, по мере готовности. Я вот тут подробно написал, что там будут за изменения.

Условно:

• Добавление экспорта CMYK TIFF/PSD/JPEG не требует переписывания нутрянки и не влияет на работу всего приложения.
• Добавление панели управления цветопробой требует сравнительно несущественного переписывания нутрянки, приличная часть внутренней работы уже сделана и влита в ветку master.

Чтобы понимать уровень сложности работы, вот патч, добавляющий импорт и экспорт CMYK JPEG (уже в master): https://gitlab.gnome.org/GNOME/gimp/-/commit/f200594d1c8cdd88b93beda41023dba2630298a1

Вот патч, добавляющий загрузку CMYK(A) TIFF (уже в master): https://gitlab.gnome.org/GNOME/gimp/-/commit/93b9876405bdced7d1ce2c54a6ab1f99839c36e5

Вот патч, переписывающий загрузку CMYK PSD на правильных функциях из babl (пока не влито): https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/646/diffs?commit_id=c4a993cabbc82bdfa4ed9f5a8f18037d27267442

Вот часть упомянутой выше работы над нутрянкой: https://gitlab.gnome.org/GNOME/gimp/-/commit/0d7fed93ae248936bd13acaa43e6a858c3dc1b24

Единственная причина, по которой CMYK может задержать релиз – если парни сойдут с ума и попытаются добавить в 3.0 поддержку других цветовых моделей как режимов изображения, чего сейчас делать не планируют (и слава б-гу).

Тут кто-то даже софт на GTK1 собирал ради интереса на новой ОСи и он работал (вроде-бы i-rinat это был, но я не помню).

Я брал уже собранные бинарники GIMP и GTK+, вот тут: Простые библиотеки реализующие графический интерфейс в python (комментарий). GIMP образца 1998 года вполне себе работал на системе 2022 года.

Причем лисоводы объявили что не собираются переходить на Gtk4 ибо не видят в этом никаких плюсов.

Потому что там от Гтк только создание фрейма окна и диалог открытия файла.

чтобы протолкнуть CSD окна

Скажите, а зачем вам нужна толстая пустая СОСИСА поверх окна? Какую функцию она выполняет? Мне вот хочется, чтобы там располагались элементы управления и виджеты.

А сосиса - это как сосуля, только сосиса? )

Координаты «строка-столбец» это краеугольный камень навигации по текстовым файлам. Всякие интерактивные помощники вроде «нажал на сообщение об ошибке, оно перешло» это безусловно, хорошо и удобно, но пусть оно будет вместе с номерами строк, а не вместо них.

Так эти координаты там есть, только в MSVC++ 6 style, то бишь без линейки.

А код самого xcb посмотреть не судьба?

И как смотреть примеры корректного использования xcb внутри исходников xcb? Очень удобно?

Учитывая что почти весь софт, пишущийся для Linux, имеет отвратительную документацию (если вообще имеет), должны уже ковырять исходники.

xcb – особый случай. Самая угрёбищно недокументированная библиотека в UNIX-like. При этом ситуация не меняется уже 20+ лет. Потому что оно тоже дохлое.

Тем более так любимая линуксоидами GPL именно этого и добивалась.

Оно под MIT, если что. Это порождение и позор UNIX-like в первую очередь, а не Linux. Собственно как и вся эта иксовая недоэкосистема.

Причем лисоводы объявили что не собираются переходить на Gtk4 ибо не видят в этом никаких плюсов.

А можно почитать это объявление где-нибудь? По-моему на Gtk4 как и на Qt 6 не спешат ещё переходить из-за новизны и сырости.

А вот с либреофисом вопрос интересный - они вроде как под gtk4 понемногу портируются, и могут дропнуть поддержку gtk3 со временем.

И Chromium-like софт тоже.

Потому что там от Гтк только создание фрейма окна и диалог открытия файла.

Ты ошибаешься, Firefox вполне себе достаточно сильно опирается на GTK+: https://github.com/mozilla/gecko-dev/tree/master/widget/gtk

Вот Chromium-like они поменьше.

В GTK4 даже не субпиксельного рендеринга шрифтов. Так что готовьтесь к лютому ШГ

15 лет ЛОР доказывал, что субпиксельный рендеринг это мыло и радуга, что это ШГ и красные глаза.

А теперь внезапно выясняется, что ШГ уже не торт.

Координаты «строка-столбец» это краеугольный камень навигации по текстовым файлам.

В Pe внизу всегда показывается номер строки и колонки. С помощью сочетания Alt+, можно быстро ввести номер строчки и перейти. Так что я не вижу никакой надобности в линейке с номерами строк. Искать строки по линейке медленно и неудобно. Удобнее пользоваться инструметами.

В компиляторе и текстовом редакторе Оберона вообще нет концепции номеров строк. Компилятор выдаёт ошибки в виде числа символов от начала файла и предполагается что текстовый редактор умеет показывать маркеры ошибок в нужном месте. При трассировке стека и обработке исключений позиция в коде также указывается в виде сисла символов с начала файла так что можно определить место в коде даже если несколько команд написаны на одной строчке.

А ещё в Обероне пропорциональные шрифты в исходниках по умолчанию.

Насколько помню, дело в том, что в GTK2 отрисовка производилась поэлементно, что позволяло начинать отображение быстрее, но могло приводить к тирингу; GTK3 же сначала дожидается рендеринга всего содержимого окна, и только затем выполняет отрисовку.

В Wayland, правда, эту проблему будут решать тупо задержкой первой отрисовки.

В Wayland просто ничего не отображается до выполнения wl_commit().

Давайте лучше WaylandX.

Ну помимо Gimp Gtk еще использует хромой, лиса м птицей, либреофис.

LibreOffice есть под Qt.

Скажите, а зачем вам нужна толстая пустая СОСИСА поверх окна? Какую функцию она выполняет? Мне вот хочется, чтобы там располагались элементы управления и виджеты.

Что? Использовать заголовок для чего-то полезного? Да вы, батенька, - интерфейсный фашист. Надо чтобы было как в виндоус 1.0. Деды ведь страдали и нам завещали.

чего сейчас делать не планируют (и слава б-гу)

Ну, действительно, слава Б-гу. А то я уже подумал, что они решили к релизу 3.0 и это запилить.

Ну помимо Gimp Gtk еще использует хромой, лиса м птицей, либреофис.

Из этого всего я пользуюсь только GIMP. На GTK3 у меня в данный момент установлены только терминал (в котором нет интерфейса, потому совершенно наплевать на чём он там) и Inkscape (спасибо GTK3 за белый текст на белом фоне!). Остальное либо на Qt5, либо на GTK2.

И как смотреть примеры корректного использования xcb внутри исходников xcb? Очень удобно?

Жизнь — боль! [2]

Линуксом и пользуюсь, вариантов всё равно не так много.

Вот, да. Значит я правильно вспомнил.

В общем-то, подтверждает тезис, что даже после EOL GTK3, если ничего настолько радикально не переломают в системе, что перестанет собираться и работать (маловеротно, но всё-таки), то, если хотят оставаться на 3, могут оставаться на ней ещё некоторое время. Совершенно не обязательно сразу бежать на 4,5,6.

А тулкитофобия заразна?

а зачем вам нужна толстая пустая СОСИСА поверх окна?

Кстати да, толстая сосиска CSD совершенно не нужна. Ещё не видел ни одной программы, где бы она была полезна. Всё можно разместить в обычном меню, а заголовок убрать средствами оконного менеджера. Или не убирать если угодно. Но фашне виднее конечно что юзеру удобнее.

Сосиса это псевдоним сардельки. И в гноме првсюду эти сардельки в интерфейсе. Начиная с совершенно пустой «панели» вверху экрана. А потом эти люди рассказывают, как они экономят пространство убирая декорации и строку меню.

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

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

У идеи и vscode вполне приличная цэ эс дэха со встроенным полноценным меню (только под линухом надо включать руками - оно типа экспериментальное, но работает нормально). Не надо судить по гномоподелиям

Я не страдаю тулкитофобией (иначе бы у меня вообще не стояло софта на GTK3), но я объективно оцениваю перспективы софта и не связываюсь с тем, чему в ближайшем будущем придётся искать замену.

Жизнь — боль! [2]

Вот потому, дабы облегчить себе эту боль, разработчики хоронят все эти Xlib, XCB, Xaw, Xt, etc и переходят на более адекватные и документированные инструменты.

и Inkscape (спасибо GTK3 за белый текст на белом фоне!)

На Adwaita всё нормально, а вот на васянских темах – такое вот. При этом подобное не только в GTK+3, но и в Qt часто бывает. Поставил какой-нибудь QtCurve или Kvantum и привет всплывающим белым подсказкам с белым текстом в программах на Qt.

В который раз убеждаюсь, что кастомизация и прочее васянство – рак, убивающий Linux-десктоп. Нужны адекватные дефолты. И у KDE и GNOME они вполне себе адекватные: Breeze и Adwaita. Ну ладно ещё Yaru убунтовский, тоже вылизанный. Остальные темы это всегда подобные глитчи и компромиссы.

А Гном нужен?

толстая сосиска CSD совершенно не нужна

Самому не смешно? Тем временем в реальности:

https://0x0.st/oQLS.png

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

И как так получилось что вся функциональность ушла в тулкиты и теперь только битмапы гоняем?

Так шрифты то больше не на стороне сервера, а сглаживаются в готовый битмап после нескольких масштабирований внутри приложения. Хорошо если не в виде 3Д поверхности на видеокарте...

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

А строго говоря и не нужно. Векторное рисование силами сервера это конечно элегантно и хорошо для сетей а значит и ногопользовательской работы через трминалы/тонкие клиенты... Но больше не важно. Отсутствие привязки содержимого окна к возможностям сервера - хорошо. Гонять битмапы через сеть - приемлимо. Особенно до тех пор, пока есть темы типа cde/redmond и быстрый алгоритм сжатия.

Ладно, согласен, есть такая функция.

Но только не надо преаращать файлменеджер (да и браузер тоже) в оконный менеджер - такой уже есть в системе. Так что если это упростило реализацию то я только за. Хотя конечно возможность быстро вызвать konsole в текущей папке это очень нужная функция, ну так её и не убрали.

Вам бы обновить снимок, а то как минимум в верхней части уже не актуально.

Ну да, инновации: на порядок меньше виджетов занимают всего лишь вдвое меньше места по вертикали. А если программе вдруг понадобится меню или тулбар, то уже совсем печально будет. Хорошо, что гномософту всегда хватает двух кнопок.

Вообще это могут быть и несколько кнопочек вдоль левого или правого края...

Давайте лучше WaylandX.

«WaylandX» появился на самых ранних этапах разработки Wayland. Называется Weston.

Есть даже композитор для единственного приложения, как раз для целей совместимости, cage.

Оффтоп. Вот вы тут всё RedHat да RedHat. А там потери. Говорят Леннарт свалил (но systemd не бросил).

15 лет ЛОР доказывал, что субпиксельный рендеринг это мыло и радуга, что это ШГ и красные глаза.

https://imgur.com/a/p5bhDAO

Если глаза не вытекли, напиши, как тебе?

Скажите, а зачем вам нужна толстая пустая СОСИСА поверх окна? Какую функцию она выполняет? Мне вот хочется, чтобы там располагались элементы управления и виджеты.

Дело в том, что CSD это - зоопарк и выкидывание менеджеров окон. В каждой DE свой менеджер окон, есть даже тайловые DE, где СОСИСЫ нет наверху. CSD плевать на то как авторы DE задумывали сделать окна. У нас в GNOME - CSD (в том числе благодаря вяленду), а вы сосите. К тому же, из-за CSD мы получили два типа окон с разным поведением, которые ещё выглядят по разному - у CSD эффекты через css темы, у обычных окон эффекты через композитор. Я очень огорчён, что это макакерство перетекло из винды в линукс. Как надо было сделать? Не делать CSD. Он не нужен, десктоп без него существовал 20 лет и гуй выглядел нормально.

У меня уже стоят два приложения на GTK4, чем ты хотел удивить?