Чем вам не нравится X11?

Так замени wm на что-нибудь нормальное, например compiz.

Потому что в иксах уже есть все фичи и это готовый проект. Там попросту нечего разрабатывать.

Дофига там чего разрабатывать.

• Изоляцию приложений.
• Многоуровневую систему захвата ввода, чтобы зависшее меню больше не приводило к необходимости переключаться в VT, а программа, захватившая клаву, позволяла себя скриншотить.
• Куча мелких багов, типа проблемы с переключением раскладки по alt+shift.

Никто это просто делать не хочет.

Изоляцию приложений.

Wayland уже за иксы это сделал. Запускаешь прогу по схеме App -> Wayland compositor -> Xorg вот тебе и изоляция. Только скринкастинг не работает и общего буфера обмена нет.

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

Я не понял, можно какие-нибудь примеры?

Куча мелких багов, типа проблемы с переключением раскладки по alt+shift.

УМВР.

Спрашивается, накой вязаться на уродливые и неказистые диалоги X11 в 2023 году, если GTK+ дефакто (нравится это кому или нет) стал уже неким «стандартным тулкитом»?

Если бинарник завязать на GTK+ 1, то в момент выбрасывания GTK+ 1 из дистрибутивов бинарник перестаёт работать. Если его завязать на GTK+ 2, то он ещё будет работать, но уже сейчас очень даже из известного консервативностью Debian активно выбрасывают софт, застрявший на GTK+ 2 с дальнейшим прицелом на выбрасывание самого GTK+ 2. Так что довольно скоро бинарник, завязанный на GTK+ 2 перестанет работать. GTK 3 уже тоже устарел, вместо него вовсю GTK 4, и уже планируют, что выбросить из GTK 5. Так что вне зависимости от того, на какой GTK ты завяжешься, твой бинарник устареет, и довольно скоро.

Так что в SDL правильно сделали, что использовали функции отрисовки шрифтов из Xlib. У них гораздо больше шансов выжить.

Не нравится шрифт? Направь претензии в SDL. Это они решили захардкодить название шрифта.

Самое забавное, так это что SDL делает под Wayland. Они запускают zenity. 🤣

Да не выбросят GTK2 никогда походу. GTK3 последняя вменяемая версия, на GTK4 софта нет и не будет вероятно. А ты про GTK5 рассказываешь.

браузеры вроде Chrome и Firefox кидают битмапы, а не примитивы, а сетевая прозрачность в иксах сосёт

С Firefox по этому поводу забавная история. На протяжении почти двух десятков лет там использовался XRender. Ну использовался и использовался. Потом в HTML пришёл Canvas, и в Firefox реализовали рисование через XRender. Кажется, опосредовано через Cairo, но не суть. И вот тут выяснилось, что стабильность браузера стала сильно зависеть от качества видеодрайверов, которые качеством не отличались. Через некоторое количество багрепортов в Firefox отключили XRender, но не только для Canvas, где проявлялась проблема, а вообще всё. Объявили, что XRender это кака, плохо, и вообще не модно. Хотя приличное время XRender продолжал использоваться, когда Firefox рисовал контролы с помощью GTK, который внезапно использовал XRender. Видимо, просто не заметили. Некоторое время XRender можно было ещё включить, и это помогло как минимум одному человеку, который пришёл пожаловаться, что вот раньше он спокойно запускал Firefox в виртуалке, пробрасывая через ssh -X, а с новой версией стало жутко тормозить. Но спустя некоторое время опцию убрали совсем. Теперь Firefox через сетевую прозрачность тормозит, а у EXL ещё один пункт в его манифесте ненависти к иксам.

Серьёзно, почему ты радуешься тому, как всё становится хуже? Ладно бы Wayland был по всем фронтам лучше. Так ведь нет же, некоторые родовые проблемы теперь будут решать костылями, если вообще будут. Технология новая, пользовательская база явно в меньшинстве, а уже нужны костыли?

Можно создавать окна в GTK для использования OpenGL.

https://habr.com/ru/articles/559004/ Gtk, OpenGL и все-все-все

Добавил в SDL код расширения SDL_ttf и все ok (хотя и не панацея).

Можно создавать окна в GTK для использования OpenGL.

Зачем? Там цель — отобразить окно с текстом. Эта часть SDL нужна, чтобы показать сообщение об ошибке. В том числе для случаев, когда не получилось завести OpenGL.

Зачем? Там цель — отобразить окно с текстом.

Весь тред не читал.

В SDL много чего для удобства нужно добавить.
Обязательно добавлю в SDL API для использования одно байтовых кодовых кодировок.
Да и в целом акцент SDL на UTF-8 ИМХО не очень, хотя и понятно для чего они так сделали.

UTF-8 ныне побеждает все иные кодировки.
Для баз данных ИМХО она не годится.

А вместо того чтобы развивать X11 в его эталонной реализации X.Org люди которые его защищают трещат на ЛОР’е, OpenNET’е и Phronix’е.

Тут явно ошибка выжившего.

Представь себе: очередная новость, упоминающая Wayland. Приходят люди, которые пользуются иксами, спрашивают, как обстоят дела с какой-нибудь фичей в Wayland. В ответы набегают фанатики всего нового и начинается «ваши иксы — копролит!» Ну и конечно же адекватность из обсуждения испаряется, а с обоих сторон остаются исключительно фанатики, которым нравится бросаться друг в друга гуано.

Большая часть нужных фич в иксах работает. Иксы за годы обросли гигантским слоем костылей, но эти костыли обеспечивают хоть какую-то работу. Есть проблемы, но эти проблемы не простые, и их решение в универсальном виде — далеко не тривиальное. С одной стороны да, Wayland предлагает решение части этих старых очевидных проблем. Но с другой стороны он ломает что-то работающее. К примеру, кривые калибровки цвета. У меня после калибровки монитора глаза перестали уставать. Я до первой калибровки и не знал, что для меня это важно. Теперь вот знаю. Что у нас там в Wayland? Разброд-шатание. Вроде есть какие-то подвижки, но они начались только в 2020-м и ещё в процессе. А Wayland’у уже сколько, 14 лет? УЖЕ ДЕСЯТИЛЕТИЕ ПРОШЛО. А что там фанатики Wayland говорят? ЭТОЙ ФИЧИ НЕТ, ОНА НЕ НУЖНА.

Мне вот интересно, сколько людей вроде меня страдает от плохой цветопередачи в мониторах, но ещё не знает о причинах.

GTK+3

GTK 3 тоже без плюса теперь. Посмотри в их документации.

В том-то и мякотка, что не в Qt, а в KWin сделали! В Wayland-сервере. Оно рубит полностью PRIMARY BUFFER во всех тулкитах, потому что некуда копировать.

То есть когда в ядре добавляют особое поведение для процесса, если его название начинается с X, чтобы обойти кривизну, это плохо. А когда в сервере добавляют костыль, чтобы обойти кривизну клиентов, это хорошо. Всё правильно?

Собрал picom 10.2 и... всё летает с --vsync! Вот и сиди на штабильных дистрах. Даже подумываю вернуться на красноглазый wm теперь. Остается только косяк со странными цветами рамок в некоторых окнах. Но этим можно пренебречь.

Серьёзно, почему ты радуешься тому, как всё становится хуже? Ладно бы Wayland был по всем фронтам лучше.

Так это ещё с какой стороны посмотреть. Те раздражающие меня проблемы с иксами вроде монопольного захвата ввода или как раз вот этого неконфигурируемого захардкоженного PRIMARY BUFFER в Wayland-серверах наконец-то пофиксили, а в X.Org они останутся на века.

Да, конечно, появились некоторые новые проблемы. Но с Wayland есть бОльший шанс что их пофиксят, так как реализации Wayland-серверов теперь подконтрольны разработчикам DE и они могут изменять их функциональность не взирая что где-то там сломается xroach и xsnow которые и так 15 лет как сломаны если испольузется композитинг.

То есть когда в ядре добавляют особое поведение для процесса, если его название начинается с X, чтобы обойти кривизну, это плохо. А когда в сервере добавляют костыль, чтобы обойти кривизну клиентов, это хорошо. Всё правильно?

Некорректная аналогия. Ядро Linux никоим образом не должно быть зависимо от технологий X11, Wayland или любых других протоколов/реализаций оконной системы, тогда как оконный сервер явно предоставляет клиентам ту функциональность, которая может быть отключена как на стороне сервера, так и на стороне клиента.

И это ещё очень хороший вопрос, внесли костыль разработчики KDE или сделали всё по уму. Лично для меня костыли это вот это вот иксовое дерьмо в репозиториях Linux:

• https://launchpad.net/~nrbrtx/+archive/ubuntu/xorg-hotkeys
• https://aur.archlinux.org/packages/xorg-server-bug865
• https://forum.altlinux.org/index.php?topic=46697.0

Которое появилось как раз из-за хреновой неконфигурируемой захардкоженной иксовой архитектуры.

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

И вот, кстати, что пишут разработчики KDE насчёт того, что оконный сервер теперь подконтролен им:

Why Plasma needs Wayland?

X has some serious issues and is rather old. The protocol is designed for the usecases three decades ago. Over the last years more and more functionality has been moved from X either into the kernel or into the compositors. The X server is more or less only a proxy between kernel, compositor and the X clients.

Today the compositor does everything the X server used to do. There are some remaining features not yet moved into the compositor (e.g. input handling) but those would make most sense in the compositor. The best situation would be to let the compositor directly work together with the kernel for rendering and input handling and manage the clients directly, which means to remove the Proxy. This is what Wayland is about. More reasons for Wayland in the FAQ.

In Plasma we need Wayland support as we are hitting the limitations of X all the time. Wayland will simplify our architecture and allow us to composite the screen in the way we consider as most useful.

https://community.kde.org/KWin/Wayland#Why_Plasma_needs_Wayland?

И как мы видим на практике, это действительно так и получилось. KDE разработчики не могли исправить некоторые раздражающие их иксовые баги и внести новую функциональность, потому что какие-то там луддиты и «X11 Veterans» в иксах тоже ныли о правильности архитектуры, о том что всё должно фиксится на стороне клиентов, а код иксовой священной коровы трогать низзя, только в рамочке он стоять должен и т. д.

Короче весь тот убогий иксовый подход, который плодил пакеты xorg-server-bugXXX в репозиториях вместо требуемого уровня настраиваемости и конфигурируемости.

И теперь, когда реализация оконного сервера наконец-то подконтрольна разработчикам KDE они и рады вносить в неё новые фичи типа отключения этой вставки по колесу, которое 20 лет требовали от них пользователи, делая Linux-десктоп удобнее. И давно надо было так сделать, ещё в начале нулевых.

неконфигурируемого захардкоженного PRIMARY BUFFER

В иксах нет хардкода PRIMARY как такового. Там есть поддержка нескольких буферов. Сейчас два, раньше вроде было больше. В иксах есть механизм, который позволяет приложениям сказать серверу «теперь я владею содержимым вот такого-то буфера», и есть механизм, который позволяет другим приложениям узнать, кто владеет содержимым буфера.

Когда ты нажимаешь колёсико мыши (или среднюю кнопку, есть нет колёсика), окно получает событие нажатия кнопки мыши. Тулкит (GTK, Qt) в рамках приложения обрабатывает событие, делает запрос к иксам «у кого сейчас PRIMARY?». Иксы отвечают, мол, вот это окно. Тулкит в рамках приложения посылает назначенному окну запрос, получает ответ, производит вставку.

Внутри иксов нет выделенного механизма обработки именно колёсика мыши. Иксы даже не различают между собой PRIMARY и CLIPBOARD. Это делают тулкиты. Это они решают, что ты решил испортить текст, который набирал, потому что случайно нажал ладонью на тачпад. Проблема в GTK, Qt, … и так далее.

Чинить эту проблему на транспортном уровне всё равно что пытаться блокировать веб-рекламу, добавляя конфиг и код в ядро Linux, потому что трафик проходит через ядро. Наверное, лучше бы всё-таки это делать в браузере.

Да, конечно, появились некоторые новые проблемы. Но с Wayland есть бОльший шанс что их пофиксят

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

Чинить эту проблему на транспортном уровне

Это более чем нормальная практика, учитывая что сегодня есть с десяток тулкитов, в которых по историческим и другим причинам реализация PRIMARY BUFFER вышла неконфигурируемой и неотключаемой. Возможно именно потому что разработчики этих тулкитов понадеялись что в иксах оно конфигурируется когда использовали Xlib или XCB.

В сухом остатке на сегодняшний день:

Решение вида – рубим PRIMARY BUFFER в конфиге оконного сервера и решаем проблему сразу со всеими 10-ю тулкитами разом – более удобно и предпочтительнее для конечного пользователя оконной системы или окружения. Что собственно и продемонстрировали разработчики KDE.

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

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

Отличия я вижу в следующем:

1. Есть «божок А», раздражающие лично меня проблемы в котором никто не хочет фиксить. И надежда на то, что они когда-то будут исправлены тает с каждым днём.

2. Есть «божок Б», который УЖЕ пофиксил раздражающие лично меня проблемы. Да, к сожалению, привнеся ворох некоторых других проблем. Но в случае «божка Б» по-крайней мере ещё есть надежда на то, что эти проблемы будут пофикшены. Работа-то во всю кипит.

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

И теперь, когда реализация оконного сервера наконец-то подконтрольна разработчикам KDE

Ничего она не подконтрольна. Теперь она под контролем фанатиков из Wayland с правом вето на принятие новых протоколов.

Ничего она не подконтрольна. Теперь она под контролем фанатиков из Wayland с правом вето на принятие новых протоколов.

Если бы это было так, в KDE Wayland и Sway WM не появились бы Server-Side Decorations, а они появились.

Это фальшь, ты с собой не честен.

Это более чем нормальная практика

Возможно, но тем не менее это костыль, а не нормальное решение проблемы.

Возможно именно потому что разработчики этих тулкитов понадеялись что в иксах оно конфигурируется когда использовали Xlib или XCB.

Это очень странное предположение, потому что для реализации копирования-вставки нужно полностью понимать механизм копирования-вставки.

Решение вида – рубим PRIMARY BUFFER в конфиге оконного сервера и решаем проблему сразу со всеими 10-ю тулкитами разом – более удобно и предпочтительнее для конечного пользователя оконной системы или окружения. Что собственно и продемонстрировали разработчики KDE.

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

Решение вида – бегаем по конфигам 10-и тулкитов и отключаем в каждом – напротив, костыльно и неудобно.

Наоборот, это как раз прямое решение, а не костыль. Оно не является простым в смысле «easy», но является простым в смысле «simple».

И порождает подобное решение как раз неконфигурируемость транспортного протокола иксов.

Мегалол. Это насколько же сильно нужно увязнуть в идеологии, чтобы такой бред заявлять. В протокол не встроили ЦЕНЗУРУ. Какой кошмар! Как же мы без цензуры в протоколе?

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

Для многого из этого владельцы Wayland явно говорят что принимать не будут.

Знаешь, что ещё забавно? Так это то что по сути DE затащили в себя иксы и теперь каждый возится со своим форком. Они уже заметно расползлись до частичной несовместимости. По сути каждый теперь играется со своим аналогом «xorg-server-bugXXX». Но ты это считаешь нормальным. А вот сам «xorg-server-bugXXX» это сразу убого.

И что ты почему-то не хочешь признавать это костылём и всячески извиваешься.

Потому что «костыль» –

• Моментально решает проблему, которая возникала у меня и ещё огромного количества пользователей Linux-дистрибутивов одной галочкой.

Тем временем «не костыль» –

• Требует чтобы пользователи правили конфиги всех системных и дополнительно установленных графических тулкитов.
• Ничего не может предложить в том случае если какой-то графический тулкит не поддерживает конфигурацию этой фичи.
• Породит ещё один пакет xorg-server-bug-mouse-whell в репозиториях в будущем, если пользователи сами захотят решить эту проблему, как в случае проблем с обработкой иксовых шорткатов.

Это насколько же сильно нужно увязнуть в идеологии, чтобы такой бред заявлять.

Идеология это как раз вот в лагере X11, где вместо того чтобы изменять протокол под потребности пользователей и решать проблемы популярных фреймворков в т. ч., забили на его развитие и теперь эти самые пользователи делают пакеты xorg-server-bug865.

Вон, KDE-разработчики как раз показали что неидеологизированы, они встроили нужную конфигурируемую функциональность в оконный сервер и kwin-wayland-server-bugXXX у них не появился. И не рассусоливали на тему того что пользователь KDE должен пойти и поправить конфиг в каждом из 10 актуальных графических тулкитов.

По сути каждый теперь играется со своим аналогом «xorg-server-bugXXX». Но ты это считаешь нормальным.

Так откуда это взялось? От хорошей жизни? Или может быть потому что xorg-server-vanilla стал почему-то внезапно неподдерживаемым как какой-нибудь Xaw? И разработчики DE вроде KDE и GNOME и всяких Sway WM теперь действительно рады ковыряться со своими аналогами xorg-server-bugXXX, как минимум потому что они там могут вносить требуемую им функциональность для работы и фиксить все те раздражающие баги фиксы которых были «не в нос» архитектурщикам X.Org.

По-крайней мере KDE разработчики открыто об этом пишут. Их цитату и привёл выше. Значит эта проблема действительно существует и только так они могут её решить.

А вот сам «xorg-server-bugXXX» это сразу убого.

Конечно это убого. Было бы не убого если бы иксы позволяли выставить строчку в конфиге вида «реагировать на отжатие клавиатурных сочетаний, а не нажатие» или «отключить PRIMARY BUFFER», но вместо этого тебе предлагается стать мейнтейнером копии патченных иксов с пофикшенными багами – обновлять их самостоятельно, реагировать на уязвимости в них, разрешать конфликты с ванильными иксовыми пакетами и т. д. Вся та пустая трата времени и дублирующаяся работа, которую и так выполняют мейнтейнеры ванильных иксов. Там где конфиг/галочка сделала бы это удобно и быстро – предлагается форменный пердолинг в угоду какой-то там мнимой иксовой архитектурности. Смех.

Требует чтобы пользователи правили конфиги всех системных и дополнительно установленных графических тулкитов.

Как раз можно было бы в X11 или D-Bus добавить интерфейс получения доступа к общим настройкам GUI единых для всех тулкитов, в том числе использования вставки по средней кнопке мыши.

Как раз можно было бы в X11 или D-Bus добавить интерфейс получения доступа к общим настройкам GUI единых для всех тулкитов, в том числе использования вставки по средней кнопке мыши.

Да конечно можно было, развивайся бы X11 в ногу со временем и потребностями Linux-десктопа или даже UNIX-десктопа. Но сегодня ситуация удручающая, X11 как протокол уже не развивают, а какой-нибудь «D-Bus GUI Settings» на который могли бы подвязаться все тулкиты – не завезли и не завезут. Графический стек разработчикам Linux-дистрибутивов надо было проектировать самим в стародавние времена, а не брать «готовенькое».

Если играть от того, что имеем именно на сегодняшний момент – сложно придумать более адекватное и удобное решение проблемы, чем то предоставили разработчики из KDE. Вариант «бегай по конфигам GTK+2, GTK+3, GTK 4, Qt 4, Qt 5, Qt 6, Swing/AWT, SWT, Mono и пр.» уж точно не является адекватным. И точно никогда не будет воплощён в жизнь, учитывая что во все эти тулкиты продвинуть патчи конфигурируемости невозможно по практическим и всяким политическим причинам вида «несмотря что на этом фреймворке куча ПО, мы принимаем патчи только в новую версию».

Вывод то прост.

Нужно развивать X11, а «народ» (GTK, ...) «подтянутся».

Хорошо если бы в этом треде было чётко сформулировано, что нужно добавить или изменить в X11.

В диалогах треда об этом сказано, но лучше всё свести к некоему RFC, который кто-либо реализует в коде.

RFC сразу не «рождаются».
Сначала черновик => обсуждение => ... => опа, RFC готов!

Предлагаю i-rinat поручить начальную разработку RFC.

Посмотрел «по диагонали» проекты https://wandrien.github.io/.

Толковый разработчик и судьба X11 ему не безразлична.
Вполне и он смог бы начать разработку RFC (на ЛОР вести обсуждение).

ЛОР, предлагайте «как лучше», ...

Возможно именно потому что разработчики этих тулкитов понадеялись что в иксах оно конфигурируется когда использовали Xlib или XCB.

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

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

Как раз можно было бы в X11 или D-Bus добавить интерфейс получения доступа к общим настройкам GUI единых для всех тулкитов, в том числе использования вставки по средней кнопке мыши.

Всё уже есть:

https://specifications.freedesktop.org/xsettings-spec/xsettings-latest.html

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

А граждане без критического мышления такие как EXL готовы верить в любой красивый вздор.

Для меня является неадекватной ситуация когда вместо того, чтобы сделать небольшую правку сервера мне предлагают идти и пропатчить 10-15 графических тулкитов которые в отличие от сервера уже не поддерживаются.

А уж ситуация когда пользователи вынуждены ставить xorg-server-bug865 вместо того чтобы сделать изменение в конфиге – ещё более далека от адекватности.

Для меня является неадекватной ситуация, когда тебе в голову приходит идея, что кто-то мог рассчитывать на то, что прикладная логика будет контролироваться транспортной библиотекой. Нет, конечно такие кадры есть: вот например ты. Но разработчики тулкитов обычно люди более технически грамотные.

Код кто писать будет?

Не знаю.
Скорее всего - вы (но RFC нужен).

Нет, конечно такие кадры есть: вот например ты

KDE-разработчики однако не поленились и сделали это конфигурируемым, как бы все эти различные «X11 Veterans» не брюзжали про «костыли» и «неархитектурно», не забывай про это.

Им пришло то же самое решение которое когда-то пришло в голову мне и теперь оно в их DE и пользователи KDE рады его использовать, пока пользователи X11 вынуждены «архитектурно» страдать. Бгг.

Но разработчики тулкитов обычно люди более технически грамотные.

Это не тех ли разработчиков тулкитов вы на пару с X512 материли в начале этой темы, которые не смогли осилить сделать PRIMARY BUFFER и другие вещи конфигурируемыми в свои проектах?

Это как-то отменяет тот факт, что они грамотнее тебя?

Этот «толковый разработчик» целыми днями болтает на лоре и бьётся с модераторами за флуд вместо того, чтобы код писать.

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

Скорее всего - вы

Любой каприз за ваши деньги))

Ну или бартер: вы мне ремонт в квартире, а я в это время пишу код)

Это как-то отменяет тот факт, что они грамотнее тебя?

Эм, а разве кто-то и когда-то пытался оспорить этот факт? Они несомнено грамотнее меня и собственно практически всех пользователей этого форума. За их плечами проекты с мировым именем Qt и GTK+, которыми пользуются миллионы других разработчиков, а не форумный трёп.

Нужно развивать X11, а «народ» (GTK, …) «подтянутся».

Это GTK подтянется, который Рассматривается возможность прекращения в GTK5 поддержки X11? Ох и святая наивность.

Хорошо если бы в этом треде было чётко сформулировано, что нужно добавить или изменить в X11.

Да черновики давно были написаны: https://www.x.org/wiki/Development/X12/

wandrien: Код кто писать будет?

Forum0888: Не знаю. Скорее всего - вы (но RFC нужен).

Написать код или просто попытаться зафиксить все шереховатости и проблемы X11 это даже не полдела. Гораздо больше работы потребуется для того, чтобы проекты по типу GTK+, Qt, GNOME, KDE и др. взявшие курс на Wayland и начавшие осваивать полученные средства решили хотя бы не добивать уже имеющуюся у них поддержку X11.

Ещё сложнее будет заставить разработчиков из Intel, Nvidia, AMD которые пишут драйвера и в последнее время делают заявления по типу «It’s Time To Admit It: The X.Org Server Is Abandonware» пересмотреть их и развернуться на полдороги.

Написать код или просто попытаться зафиксить все шереховатости и проблемы X11 это даже не полдела.

Это много лучше, чем лишь одни бесконечные обсуждения.

Не вижу никого, кто хотел бы писать код. Только желающие пообсуждать.

Шутка

Просто этот тред ещё не читал «настоящий писатель».

В ядре костыли для иксов

В квине костыли для тулкитов

https://www.youtube.com/watch?v=B7GkKiiPT7c

Только желающие пообсуждать.

Если ты не заметил, тут форум, а не гитхаб.

Предлагаю i-rinat поручить начальную разработку RFC.

Окей, начну.

diff --git a/rfc b/rfc
new file mode 100644
index 0000000..051647c
--- /dev/null
+++ b/rfc
@@ -0,0 +1,2 @@
+Надо делать, как надо. А как не надо делать, делать не надо.
+

Спасибо!

Надеюсь что всё будет ok!

Это много лучше, чем лишь одни бесконечные обсуждения.

Предлагаю (за неимением квалификации в программировании под xorg) натравить chatgpt на иксы :)

А кто на форуме спец по chatgpt?

Может кому пригодится (поисковая строка «программирование xorg»).

https://habr.com/ru/articles/148954/ Графический стек Linux

http://rus-linux.net/MyLDP/BOOKS/Linux-tools/GUI_01.html Создание графических приложений

...

Будто там они есть)

Так-то если кто адекватную оконную систему пилит, я бы может присоединился.