Это если в обязательном порядке есть тулкит, в котором есть поддержка тем и нюансов стилизации конкретного DE.
Во-первых, приложению может быть и не нужен тулкит, если у него нет обычного UI. Когда началась эта катавасия с CSD в Gnome, отвалилось оформление целой кучи разных приложений: игры, плееры, терминалы. Часть потом полечили поддержкой libdecor в SDL, но это не исправляет суть проблемы. Зачем приложению тажеленная зависимость от тулкита, если оно им не собирается пользоваться?
Во-вторых, мир опять-таки не ограничивается GTK и Qt. Формально, в Linux может быть неограниченное количество самых разных тулкитов для самых разных целей, и все они должны поддерживать возможные закидоны всех мыслимых DE?
Общие декорации это не атавизм, а то, что ожидает разработчик приложения по умолчанию. В подавляющем большинстве случаев они предоставляются тулкитом, но вариант создания окна напрямую через X или Wayland ничем по смыслу не отличается от создания окна напрямую через WinAPI или Cocoa. Если бы у Linux был бы один официальный и всегда без вариантов доступный тулкит для UI, задачу декораций можно было бы переложить на него, как в случае с Windows или macOS. Но в Linux в качестве такого "тулкита" выступают X и Wayland.
Нормальные же люди будут юзать экраны с нормальным DPI
Я купил 4K монитор только потому, что устал смотреть на пикселявый текст. Поставил на 4K масштаб 200%, все по размерам осталось как и было, только текст теперь нормальный.
Да, на моменте с CSD я тоже понял что добром это не кончится.
Wayland не требует от композитора поддержки SSD, клиент все равно обязан быть готовым предоставить CSD, а еще нам лень, так что давайте все реализуйте CSD.
И ведь главное находятся защищающие эту позицию. Мол раз Wayland не требует, значит можно, нет, даже не так, это правильно не поддерживать SSD. То, что причина опциональности SSD (наличие сценариев, когда SSD не имеет смысла, например телефон или киоск) не имеет никакого отношения к десктопам, никого не интересует.
Как приложение должно узнать о дизайне декораций конкретного Gnome и реализовать их в соответствии со всеми системными настройками, в точности так же, как и все остальные приложения -- тоже очень мало кого интересует. Используй GTK, что ты как маленький.
По какой-то непонятной причине мир GTK не ограничивается. Но поскольку предоставлять декорации по запросу клиента мы не хотим, сделаем специальную библиотеку libdecor, которая по запросу клиента предоставит декорации. Теперь любое приложение, которое не использует популярный UI-фреймворк, должно таскать с собой этот костыль для Gnome.
Для smart ptr нужны деструкторы. Их нет в стандарте
Деструкторы, которые вы имеете в виду, нужны для RAII.
Для умных указателей формально они не нужны. FFmpeg полон использования shared ptr для управления ресурсами, GLib предоставляет функциональность shared/weak ptr и наверняка ещё куча, если не большинство сложных проектов на C так или иначе приходят к использованию подсчёта ссылок с финализацией объекта.
Для option/either/maybe нужны дженерики. Си может предложить только макросы
В виде какой-нибудь стандартной библиотеки реализовать их и вышеупомянутые умные указатели непросто.
Но в пределах одного проекта вполне возможно. Конкретизируя каждый тип и/или необходимые для него методы (av_frame_ref, ns_optional_type1, ns_either_type2_type3 и т. д.) либо вручную, либо при помощи макроса.
Мир Линукс не в какой-то волшебной стране бесконечных ресурсов расположен. На что хватит сил из того, что наиболее востребовано -- то и будет поддерживаться. Остальное останется существовать в том виде, в каком есть, пока не устареет.
Грубо говоря дропнут поддержку X в очередном мажорном релизе фреймворка потому что тесты падают, а разбираться и фиксить их некому -- и все. Либо сам пили как хочешь, либо спонсируй, либо просто возьми уже свежую версию и не занимайся ерундой, вот и весь выбор.
Приложения перестанут его поддерживать целенаправленно. При использовании "чистых" Qt, GTK и т. п. все равно что за протокол используется, но полным-полно софта, которому надо или чуть больше, или что-то специфичное, или что-то, что в Wayland пока не реализовано, или просто X дёргает потому что ну он же у всех есть.
Так как Wayland стали ставить и включать по умолчанию, с этим софтом начнутся проблемы. Это криво, то не так -- эти проблемы будут исправляться с обеих сторон, что-то в приложениях, что-то в Wayland. В определенный момент окажется, что из всего дистрибутива XWayland не использует никто и его просто выключат. И вот тут можно будет сказать, что X кончился.
Ключевой момент текущих событий в том, что ещё недавно Wayland был сугубо экспериментальной штукой, которую надо было включать целенаправленно и обычно осознанно. Теперь наоборот это вариант по умолчанию. Если пользователь поставил свежую версию ОС и софт, а он глючит или не работает -- придется править. Чем больше будет исправлено и адаптировано, тем большей дичью будут казаться оставшиеся косяки.
X перестанут использовать осознанно, но его поддержка конечно останется ещё надолго. Только никому уже не будет до этого никакого дела.
Вообще я имел в виду прям вообще весь интерфейс. Не просто изображение какого-нибудь приложения, а прямо всё нутро UI, как это пытается делать X. Это сложно, это не всегда возможно и самое главное это никому уже толком не нужно -- любой клиент уже достаточно производителен, чтобы удаленный вызов самых различных функций по работе с условной кнопкой вместо передачи ее изображения был неэффективным и ненадежным кромчиловом.
Ваш сценарий работы довольно специфичен, но даже в нем X на самом деле не нужен. Ну, в смысле можно было бы сделать все то же самое и без X. Просто так вышло, что для X в силу исторических причин уже все есть, а для Wayland никто и не подумал делать.
Если будет спрос на чрезвычайно оптимизированный вариант проброса GUI окна или его части -- сделают и для Wayland. Но пока ситуация такова, что чаще всё-таки нужно пробросить рабочий стол или окно ровно как оно есть, со всеми особенностями и нюансами, один в один, и не морочить голову. Ваш сценарий работы может быть очень даже обоснован, но объективно ради небольшого количества человек никто не будет городить всю эту бесполезную канитель с выполнением GUI как будто это web-сервис какой-то на удаленной машине.
Ну и по конкретному сценарию работы. Вы же на локальной машине или хотя бы в локальной сети все крутите если я правильно понял. Зачем тут вообще проброс GUI? Локально есть просто монитор виртуальной машины, в локальной сети любой способ доступа к удалённому столу будет работать прекрасно. Более того, если окно виртуальной машины чем-то не нравится (я просто делаю его нужного размера и разворачиваю внутри окно нужного мне приложения в полный экран), то у VirtualBox и VMware есть seamless mode, который позволяет вытащить окно гостя на рабочий стол хоста.
Ну то есть это реально выглядит как решение проблемы, которой по сути и нет, а X это такой костыль, который чисто случайно подошёл.
Да, уровень поддержки X и Wayland сильно отличается. В одном будут править баги и добавлять современную функциональность, а во втором -- нет.
Приложения, которые не будут поддерживать Wayland, относительно скоро потеряют пользовательскую базу. Да, Wayland далеко не идеал, но X все. Можно сколько угодно сетовать, что в Windows 11 все плохо, телеметрия, кривое поделие с сомнительными решениями, и пытаться сидеть на вылизанной и стабильной XP -- но все, поезд ушел. Сидите сколько хотите, весь остальной мир будет жрать совсем другой кактус.
Qt, GTK и прочие фреймворки абстрагируют работу с элементами UI. Они предоставляют свой собственный API, а уж с использованием чего он реализован -- приложение, в идеале, знать не должно. В Linux они реализованы поверх X11 и, теперь, ещё и Wayland, в Windows -- поверх WinAPI, в macOS -- поверх Cocoa и т. д.
Qt это вообще один из наиболее популярных кроссплатформенных фреймворков для GUI, он в принципе не может работать только через X11.
Проблема комментариев, которые легко писать и поддерживать, в том, что они описывают что происходит, а не почему и зачем.
Что код/функция/модуль делает можно худо-бедно понять по самому коду. Куда важнее информация зачем вообще этот код нужен, почему код делает именно так, а не очевидно более простым образом и в каком направлении его можно менять, а в каком лучше не стоит -- пробовали, не получилось.
Но такие комментарии парой строк перед функцией уже не напишешь и такую информацию очень сложно поддерживать в процессе более-менее активной разработки.
Вот и получается, что описаний функций с аргументами полно, а логику и практики применения можно найти только в статье или вообще монографии опытного пользователя.
Соглашусь, утверждение было сформулировано слишком категорично.
Однако я имел в виду обычные, популярные протоколы доступа к удалённому рабочему столу, где не предполагается много видео. В таком случае старый добрый подход с как бы, типа, если один глаз закрыть, lossless передачей пожатых прямоугольников с изменившимися пикселями работает на удивление хорошо.
Хотя с современными кодеками, которые сами могут разбить кадр на произвольные области с индивидуальными параметрами сжатия, граница становится довольно размытой. Не удивлюсь, если к AV2 или H.266 проще и эффективнее будет тупо кодеком весь экран пожать с указанным битрейтом и не париться.
Вы вероятно плохо представляете, как сложен современный UI. Те "свистелки и переделки", которые навертели поверх того самого старого доброго X -- это уже неотъемлемая часть работы большинства приложений, от общей композиции рабочего стола до нормальных шрифтов и аппаратного ускорения.
Добрая часть UI уже давно не будет работать по сети в том виде, в котором это задумывалось в X изначально, часть вещей в принципе не может работать по сети и явно или косвенно опирается на предположение, что все локально. А худо-бедно прокидывается оно потому, что вместо высокоуровневых примитивов там передаются целые области изображения -- как в VNC (а не VPN, надеюсь вы просто опечатались), только криво.
В итоге "как задумано" оно работает только в примитивных сценариях, которые нельзя назвать общим решением. Либо оно работает так же, как и остальные протоколы, только ещё и X там ни к селу, ни к городу.
Во-первых, видео а-ля стриминг игр нигде и не перекачивается, ни в плохом качестве, ни в каком.
Во-вторых, если ни один из этих протоколов не работает если связь меньше мегабита, ну значит для этой задачи объективно надо мегабит.
X просто не подходит, даже если он по тоненькому каналу может работать. Если "не передавать контент вне оконных примитивов", ограничившись только чистым X, то это будет работать только с X, то есть в довольно ограниченном виде. Если вам хватает простецких окон терминала и блокнота с древними шрифтами -- прекрасно, остальному миру не хватило. Если же прокинуть через X десктоп с композицией, а в нем ещё и современный браузер, то там уже по сути VNC начинает ходить, то есть все те же копии картинок.
Ни один из распространенных на практике протоколов удаленного доступа к рабочему столу не использует модель X. И тем не менее, все прекрасно работает без "перекачивания видео по сети в плохом качестве" =).
Вариант с передачей по сети команд по работе с фиксированным набором относительно высокоуровневых примитивов пользовательского интерфейса (окна, контролы, текст и т. п.) просто не работает в общем виде. Современный десктоп намного сложнее в графическом плане.
Поэтому все просто используют передачу изменившихся областей экрана. При этом используется множество оптимизаций, например Microsoft RDP может посылать информацию о высокоуровневых примитивах если клиент сможет их точно воспроизвести, но это всё-таки оптимизации, а не фундаментальный принцип работы.
Зачем нужен Wayland это тема для отдельной огромной статьи. Возможно, проще будет погуглить и по диагонали пролистать тезисы.
Если очень кратко и очень грубо, то X это очень старый протокол, который разрабатывался едва ли не целиком вокруг идеи удаленной работы клиентов, во времена, когда ни о безопасности в нынешнем понимании, ни об аппаратном ускорении не задумывались.
За тридцать с лишним лет приоритеты и практики разработки поменялись. Прокидывать интерфейс по сети никому не нужно (не стоит путать с удаленным рабочим столом), при декодировании видео на YouTube нежелательно даже лишнее копирование (потому что это дополнительные милливатты драгоценной батареи ноутбука или телефона), а воровать пароли и вовсе некрасиво.
X11 латали костылями изо всех сил, но в какой-то момент надоело.
С X11 скорее всего случится то, что приложения просто лавинообразно перестанут его поддерживать.
Большинство и так написаны с использованием основных фреймворков типа Qt или GTK, они даже не заметят что что-то произошло. Другие разработчики будут вынуждены переписать/обновить, потому что приложения при работе через X начнут выглядеть плохо (дробное масштабирование нынче все более распространено), не будут поддерживать всякие модные жесты, не смогут взаимодействовать с остальными приложениями в системе, появятся проблемы с задействованием новых API аппаратного ускорения и прочие мелочи, которые будут продолжать копиться.
И тем не менее, основные дистрибутивы уже включают Wayland по умолчанию (плюс конечно XWayland на фоне).
С Wayland смешно уже конечно, ему 15 лет уже, ещё через 6 ему будет столько же, сколько было X11 когда начали разрабатывать Wayland, можно будет новый проект запускать. Мне самому кое-какие моменты в разработке Wayland не нравятся.
Но то, что X11 все это факт. В нем даже баги кроме безопасности не правят уже. В ближайшее время все фреймворки переползут на Wayland и все, пользователя даже спрашивать не будут.
Это если в обязательном порядке есть тулкит, в котором есть поддержка тем и нюансов стилизации конкретного DE.
Во-первых, приложению может быть и не нужен тулкит, если у него нет обычного UI. Когда началась эта катавасия с CSD в Gnome, отвалилось оформление целой кучи разных приложений: игры, плееры, терминалы. Часть потом полечили поддержкой libdecor в SDL, но это не исправляет суть проблемы. Зачем приложению тажеленная зависимость от тулкита, если оно им не собирается пользоваться?
Во-вторых, мир опять-таки не ограничивается GTK и Qt. Формально, в Linux может быть неограниченное количество самых разных тулкитов для самых разных целей, и все они должны поддерживать возможные закидоны всех мыслимых DE?
Общие декорации это не атавизм, а то, что ожидает разработчик приложения по умолчанию. В подавляющем большинстве случаев они предоставляются тулкитом, но вариант создания окна напрямую через X или Wayland ничем по смыслу не отличается от создания окна напрямую через WinAPI или Cocoa. Если бы у Linux был бы один официальный и всегда без вариантов доступный тулкит для UI, задачу декораций можно было бы переложить на него, как в случае с Windows или macOS. Но в Linux в качестве такого "тулкита" выступают X и Wayland.
Я купил 4K монитор только потому, что устал смотреть на пикселявый текст. Поставил на 4K масштаб 200%, все по размерам осталось как и было, только текст теперь нормальный.
4k в 90 DPI это 3840 / 90 = 42.7 дюйма или 107 см по ширине. Либо у вас монитор с диагональю 48", либо все-таки масштаб 200% =).
Да, на моменте с CSD я тоже понял что добром это не кончится.
Wayland не требует от композитора поддержки SSD, клиент все равно обязан быть готовым предоставить CSD, а еще нам лень, так что давайте все реализуйте CSD.
И ведь главное находятся защищающие эту позицию. Мол раз Wayland не требует, значит можно, нет, даже не так, это правильно не поддерживать SSD. То, что причина опциональности SSD (наличие сценариев, когда SSD не имеет смысла, например телефон или киоск) не имеет никакого отношения к десктопам, никого не интересует.
Как приложение должно узнать о дизайне декораций конкретного Gnome и реализовать их в соответствии со всеми системными настройками, в точности так же, как и все остальные приложения -- тоже очень мало кого интересует. Используй GTK, что ты как маленький.
По какой-то непонятной причине мир GTK не ограничивается. Но поскольку предоставлять декорации по запросу клиента мы не хотим, сделаем специальную библиотеку libdecor, которая по запросу клиента предоставит декорации. Теперь любое приложение, которое не использует популярный UI-фреймворк, должно таскать с собой этот костыль для Gnome.
Деструкторы, которые вы имеете в виду, нужны для RAII.
Для умных указателей формально они не нужны. FFmpeg полон использования shared ptr для управления ресурсами, GLib предоставляет функциональность shared/weak ptr и наверняка ещё куча, если не большинство сложных проектов на C так или иначе приходят к использованию подсчёта ссылок с финализацией объекта.
В виде какой-нибудь стандартной библиотеки реализовать их и вышеупомянутые умные указатели непросто.
Но в пределах одного проекта вполне возможно. Конкретизируя каждый тип и/или необходимые для него методы (av_frame_ref, ns_optional_type1, ns_either_type2_type3 и т. д.) либо вручную, либо при помощи макроса.
Смотришь в паспорт -- блин, я уже старый. Смотришь в трудовую -- блин, я ещё молодой.
Мир Линукс не в какой-то волшебной стране бесконечных ресурсов расположен. На что хватит сил из того, что наиболее востребовано -- то и будет поддерживаться. Остальное останется существовать в том виде, в каком есть, пока не устареет.
Грубо говоря дропнут поддержку X в очередном мажорном релизе фреймворка потому что тесты падают, а разбираться и фиксить их некому -- и все. Либо сам пили как хочешь, либо спонсируй, либо просто возьми уже свежую версию и не занимайся ерундой, вот и весь выбор.
Приложения перестанут его поддерживать целенаправленно. При использовании "чистых" Qt, GTK и т. п. все равно что за протокол используется, но полным-полно софта, которому надо или чуть больше, или что-то специфичное, или что-то, что в Wayland пока не реализовано, или просто X дёргает потому что ну он же у всех есть.
Так как Wayland стали ставить и включать по умолчанию, с этим софтом начнутся проблемы. Это криво, то не так -- эти проблемы будут исправляться с обеих сторон, что-то в приложениях, что-то в Wayland. В определенный момент окажется, что из всего дистрибутива XWayland не использует никто и его просто выключат. И вот тут можно будет сказать, что X кончился.
Ключевой момент текущих событий в том, что ещё недавно Wayland был сугубо экспериментальной штукой, которую надо было включать целенаправленно и обычно осознанно. Теперь наоборот это вариант по умолчанию. Если пользователь поставил свежую версию ОС и софт, а он глючит или не работает -- придется править. Чем больше будет исправлено и адаптировано, тем большей дичью будут казаться оставшиеся косяки.
X перестанут использовать осознанно, но его поддержка конечно останется ещё надолго. Только никому уже не будет до этого никакого дела.
Вообще я имел в виду прям вообще весь интерфейс. Не просто изображение какого-нибудь приложения, а прямо всё нутро UI, как это пытается делать X. Это сложно, это не всегда возможно и самое главное это никому уже толком не нужно -- любой клиент уже достаточно производителен, чтобы удаленный вызов самых различных функций по работе с условной кнопкой вместо передачи ее изображения был неэффективным и ненадежным кромчиловом.
Ваш сценарий работы довольно специфичен, но даже в нем X на самом деле не нужен. Ну, в смысле можно было бы сделать все то же самое и без X. Просто так вышло, что для X в силу исторических причин уже все есть, а для Wayland никто и не подумал делать.
Если будет спрос на чрезвычайно оптимизированный вариант проброса GUI окна или его части -- сделают и для Wayland. Но пока ситуация такова, что чаще всё-таки нужно пробросить рабочий стол или окно ровно как оно есть, со всеми особенностями и нюансами, один в один, и не морочить голову. Ваш сценарий работы может быть очень даже обоснован, но объективно ради небольшого количества человек никто не будет городить всю эту бесполезную канитель с выполнением GUI как будто это web-сервис какой-то на удаленной машине.
Ну и по конкретному сценарию работы. Вы же на локальной машине или хотя бы в локальной сети все крутите если я правильно понял. Зачем тут вообще проброс GUI? Локально есть просто монитор виртуальной машины, в локальной сети любой способ доступа к удалённому столу будет работать прекрасно. Более того, если окно виртуальной машины чем-то не нравится (я просто делаю его нужного размера и разворачиваю внутри окно нужного мне приложения в полный экран), то у VirtualBox и VMware есть seamless mode, который позволяет вытащить окно гостя на рабочий стол хоста.
Ну то есть это реально выглядит как решение проблемы, которой по сути и нет, а X это такой костыль, который чисто случайно подошёл.
Да, уровень поддержки X и Wayland сильно отличается. В одном будут править баги и добавлять современную функциональность, а во втором -- нет.
Приложения, которые не будут поддерживать Wayland, относительно скоро потеряют пользовательскую базу. Да, Wayland далеко не идеал, но X все. Можно сколько угодно сетовать, что в Windows 11 все плохо, телеметрия, кривое поделие с сомнительными решениями, и пытаться сидеть на вылизанной и стабильной XP -- но все, поезд ушел. Сидите сколько хотите, весь остальной мир будет жрать совсем другой кактус.
Qt, GTK и прочие фреймворки абстрагируют работу с элементами UI. Они предоставляют свой собственный API, а уж с использованием чего он реализован -- приложение, в идеале, знать не должно. В Linux они реализованы поверх X11 и, теперь, ещё и Wayland, в Windows -- поверх WinAPI, в macOS -- поверх Cocoa и т. д.
Qt это вообще один из наиболее популярных кроссплатформенных фреймворков для GUI, он в принципе не может работать только через X11.
Проблема комментариев, которые легко писать и поддерживать, в том, что они описывают что происходит, а не почему и зачем.
Что код/функция/модуль делает можно худо-бедно понять по самому коду. Куда важнее информация зачем вообще этот код нужен, почему код делает именно так, а не очевидно более простым образом и в каком направлении его можно менять, а в каком лучше не стоит -- пробовали, не получилось.
Но такие комментарии парой строк перед функцией уже не напишешь и такую информацию очень сложно поддерживать в процессе более-менее активной разработки.
Вот и получается, что описаний функций с аргументами полно, а логику и практики применения можно найти только в статье или вообще монографии опытного пользователя.
Соглашусь, утверждение было сформулировано слишком категорично.
Однако я имел в виду обычные, популярные протоколы доступа к удалённому рабочему столу, где не предполагается много видео. В таком случае старый добрый подход с как бы, типа, если один глаз закрыть, lossless передачей пожатых прямоугольников с изменившимися пикселями работает на удивление хорошо.
Хотя с современными кодеками, которые сами могут разбить кадр на произвольные области с индивидуальными параметрами сжатия, граница становится довольно размытой. Не удивлюсь, если к AV2 или H.266 проще и эффективнее будет тупо кодеком весь экран пожать с указанным битрейтом и не париться.
Вы вероятно плохо представляете, как сложен современный UI. Те "свистелки и переделки", которые навертели поверх того самого старого доброго X -- это уже неотъемлемая часть работы большинства приложений, от общей композиции рабочего стола до нормальных шрифтов и аппаратного ускорения.
Добрая часть UI уже давно не будет работать по сети в том виде, в котором это задумывалось в X изначально, часть вещей в принципе не может работать по сети и явно или косвенно опирается на предположение, что все локально. А худо-бедно прокидывается оно потому, что вместо высокоуровневых примитивов там передаются целые области изображения -- как в VNC (а не VPN, надеюсь вы просто опечатались), только криво.
В итоге "как задумано" оно работает только в примитивных сценариях, которые нельзя назвать общим решением. Либо оно работает так же, как и остальные протоколы, только ещё и X там ни к селу, ни к городу.
Справедливости ради, касаемо окон и пр. WinAPI это будет аналог оконного фреймворка, например того же GTK.
Если бы Linux мог себе позволить иметь один единственный официальный фреймворк для GUI, было бы намного проще.
И какое это имеет отношение к вышесказанному?
Во-первых, видео а-ля стриминг игр нигде и не перекачивается, ни в плохом качестве, ни в каком.
Во-вторых, если ни один из этих протоколов не работает если связь меньше мегабита, ну значит для этой задачи объективно надо мегабит.
X просто не подходит, даже если он по тоненькому каналу может работать. Если "не передавать контент вне оконных примитивов", ограничившись только чистым X, то это будет работать только с X, то есть в довольно ограниченном виде. Если вам хватает простецких окон терминала и блокнота с древними шрифтами -- прекрасно, остальному миру не хватило. Если же прокинуть через X десктоп с композицией, а в нем ещё и современный браузер, то там уже по сути VNC начинает ходить, то есть все те же копии картинок.
Ни один из распространенных на практике протоколов удаленного доступа к рабочему столу не использует модель X. И тем не менее, все прекрасно работает без "перекачивания видео по сети в плохом качестве" =).
Вариант с передачей по сети команд по работе с фиксированным набором относительно высокоуровневых примитивов пользовательского интерфейса (окна, контролы, текст и т. п.) просто не работает в общем виде. Современный десктоп намного сложнее в графическом плане.
Поэтому все просто используют передачу изменившихся областей экрана. При этом используется множество оптимизаций, например Microsoft RDP может посылать информацию о высокоуровневых примитивах если клиент сможет их точно воспроизвести, но это всё-таки оптимизации, а не фундаментальный принцип работы.
Зачем нужен Wayland это тема для отдельной огромной статьи. Возможно, проще будет погуглить и по диагонали пролистать тезисы.
Если очень кратко и очень грубо, то X это очень старый протокол, который разрабатывался едва ли не целиком вокруг идеи удаленной работы клиентов, во времена, когда ни о безопасности в нынешнем понимании, ни об аппаратном ускорении не задумывались.
За тридцать с лишним лет приоритеты и практики разработки поменялись. Прокидывать интерфейс по сети никому не нужно (не стоит путать с удаленным рабочим столом), при декодировании видео на YouTube нежелательно даже лишнее копирование (потому что это дополнительные милливатты драгоценной батареи ноутбука или телефона), а воровать пароли и вовсе некрасиво.
X11 латали костылями изо всех сил, но в какой-то момент надоело.
С X11 скорее всего случится то, что приложения просто лавинообразно перестанут его поддерживать.
Большинство и так написаны с использованием основных фреймворков типа Qt или GTK, они даже не заметят что что-то произошло. Другие разработчики будут вынуждены переписать/обновить, потому что приложения при работе через X начнут выглядеть плохо (дробное масштабирование нынче все более распространено), не будут поддерживать всякие модные жесты, не смогут взаимодействовать с остальными приложениями в системе, появятся проблемы с задействованием новых API аппаратного ускорения и прочие мелочи, которые будут продолжать копиться.
И тем не менее, основные дистрибутивы уже включают Wayland по умолчанию (плюс конечно XWayland на фоне).
С Wayland смешно уже конечно, ему 15 лет уже, ещё через 6 ему будет столько же, сколько было X11 когда начали разрабатывать Wayland, можно будет новый проект запускать. Мне самому кое-какие моменты в разработке Wayland не нравятся.
Но то, что X11 все это факт. В нем даже баги кроме безопасности не правят уже. В ближайшее время все фреймворки переползут на Wayland и все, пользователя даже спрашивать не будут.