Два года назад, работая над Потрясающий , я присоединился к разработке XCB , что является частью инициативы Бесплатный рабочий стол .
Мне пришлось узнать тайны протокола X11 и всего древнего и загадочного мира, окружающего его.
За последние несколько месяцев я наконец-то смыл всю эту грязь и теперь чувствую необходимость поделиться своими мыслями по поводу всего этого многолетнего бардака.
Когда меня еще не было на свете.
… группа Тото выпустил их знаменитая песня «Африка» , и несколько умных ребят работали над оконной системой X Window System (это ее полное название), которая тоже имеет (слишком) долгую историю.
Окончательная версия протокола (11-я) была разработана в 80-х годах.
Подробности истории вы можете узнать на сайте Статья в Википедии .
В 2010 году мы по-прежнему слушаем дискотеку и по-прежнему используем различные протоколы, разработанные в 80-х (и даже до Х).
Музыка развивается, протоколы меняются, а X11 не стоит на месте.
Проблема в том, что X11 развивается неправильно.
Ребята из MIT и всех других мест со смартами создали первую версию X в 1984 году и вносили изменения вплоть до 11-й версии протокола.
Он был выпущен в 1987 году и мы используем его до сих пор.
За 3 года было выпущено одиннадцать версий в полном соответствии с моделью «ранний выпуск, частые обновления».
Не знаю почему, но в течение следующих 23 лет от этого подхода отказались (хотя разработчики добавили (и удалили) множество расширений протокола).
Я не знаю, какие изменения были внесены в первые 11 основных версий протокола X, но я почти уверен, что за последние 20 с лишним лет возникла острая необходимость внести в него серьезные изменения.
По моему скромному мнению, X11 не был рассчитан на 23 года службы.
Однако я никого не виню: мне было 4 года, и я играл с Lego, когда была выпущена последняя версия Протокола X, поэтому у меня было очень мало шансов сделать что-то лучше.
Мы не исправим это.
Мы адаптируемся Это, пожалуй, главный лозунг Х-протокола последних лет. Только не поймите меня неправильно: я не собираюсь шлепать.
Протокол X11 с годами устарел, и разработчики начали его дополнять.
За прошедшие годы было добавлено множество расширений.
В точном соответствии с одним из оригинальные принципы X :
Важно четко определить, что представляет собой система, а что нет. Нет необходимости пытаться служить нуждам всего мира; вместо этого систему следует сделать расширяемой, чтобы можно было соответствующим образом удовлетворить дополнительные потребности.Все они без исключения были добавлены потому, что (увы и ах) протокол X11 не предусматривал всего того, что появилось за последние 23 года, вроде видео, OpenGL, нескольких мониторов или удовольствия от рисования овальных окон.
Некоторые из этих расширений используются до сих пор, а другие уже канули в лету.
Расширения протокола не являются чем-то плохим, но попытки исправить протокол с помощью расширений типа XИсправления Мне кажется это плохой идеей, несмотря на все добрые намерения Кита Паккарда.
На самом деле это хуже, чем вы думаете
Протокол X11 (без расширений) определяет около 120 типов запросов: создание окна, перемещение окна и так далее.Сегодня как минимум 25% из них совершенно бесполезны: использование серверных шрифтов или рисование квадратов и многоугольников не используется ни одним современным приложением или набором инструментов.
Все они переопределяются в запросах из расширений, таких как, например, XRender .
Работа с несколькими мониторами совершенно запутывает. X11 был разработан для работы в Зафод (независимые наблюдатели).
Но Ксинерама , и в наши дни XRandR полностью вытеснил его — последние версии X-сервера (примерно с 2007 года) больше не поддерживают режим Zaphod, хотя он и является частью ядра протокола X11. Хуже того: многие запросы содержат ограничения или недостатки дизайна, например, описанные в документе исследователей DEC: Почему X не является нашей идеальной оконной системой .
Мы будем накапливать больше нарушенных стандартов
После вашего оригинальные принципы ,X не определяет политику, а лишь предоставляет механизмы, что кажется правильным.В результате разработчики собрались вместе и начали писать спецификации, определяющие набор правил и догм: ИКККМ .
Это было 22 года назад, в 1988 году.
Бесполезно добавлять, что многие пункты этой спецификации уже безнадежно устарели, поскольку не учитывали многие современные технологии.
Я не единственный, кто так думает. Авторы проектов, ставших двумя основными средами рабочего стола КДЕ И ГНОМ , мы это видели уже в 90-х, когда я только учился считать.
И они написали ?.
В.
М.
Х.
, еще один стандарт, который появился поверх ICCCM и добавил ряд приятных функций (максимизация, полноэкранный режим и другие).
Проблема в том, что этот стандарт тоже писали не очень дальновидные люди, одновременно работавшие над собственными средами (GNOME, KDE и, возможно, некоторыми другими).
Эти среды рабочего стола тогда имели и до сих пор имеют ряд строгих концепций, определяющих, как должен работать рабочий стол: «у него должны быть рабочие области», «окно может существовать только в одном рабочем пространстве», «мы можем видеть».
одновременно только одно рабочее место», «у нас нет нескольких экранов» и так далее.
Чувак, не волнуйся: у нас есть наборы инструментов!
Представление о том, как должен работать рабочий стол, теперь запечатлено в каждом приложении или библиотеке, реализующей EWMH, включая ГТК+ И Qt .В результате сейчас о стандартах все просто забыли.
Инструментарии реализуют их самостоятельно, минуя ограничения и недостатки протокола X11, и никто не хочет оглядываться назад. И люди относятся к этим инструментариям так же небрежно, как и к стандартам.
Иногда это приводит к неприятным побочным эффектам.
Например, Openoffice как переключатель рабочего стола .
Мы не хотим оглядываться назад? Хуже того, мы забыли, откуда пришли!
Настольные компьютеры, со всеми этими плохо разработанными стандартами, продолжают развиваться уже более десяти лет. К нему продолжают добавляться новые стандарты, самые последние из которых основаны на D-Bus, например.Спецификация уведомлений на рабочем столе или свежий Спецификация уведомления о состоянии , разработанный в KDE. Status Notifier — это новая реализация старого доброго системного трея, основанная на XВстроить , но теперь с использованием механизмов D-шина вместо X11 и добавление возможности отображать на панели задач не только значки.
Проект спецификации содержит серьезный конструктивный недостаток, на который указал Вольфганг Драксфингер в своей работе.
обращение в список рассылки XDG .
Вольфганг отмечает, что X — сетевой протокол, а D-Bus — нет. Поэтому использование спецификации уведомления о состоянии D-Bus для передачи событий в системном трее — плохая идея: запуск графического приложения с компьютера A на компьютер B приведет к обновлению лотка на неправильном хосте! Из переписки видно, что это не пугает некоторых разработчиков KDE :
Конечно, не стоит слишком беспокоиться об этом необычном особом случае.То, что Освальд называет особым случаем, для многих из нас является наиболее типичной ситуацией.По крайней мере, вы будете думать об этом так, пока не столкнетесь с этим сами (просто протестировав что-то или установив какой-нибудь навороченный киоск)».
В общем, зависит от вашей удачи.
На мой взгляд, это шаг назад в неправильном направлении.
Но мы также можем сделать вывод, что сетевая часть X стала бесполезной, по крайней мере, для KDE.
Я предпочитаю верить в XCB
Когда я присоединился к Freedestop, мне пришлось работать над библиотекой XCB X C Binding. У XCB есть красивый и понятный API 21 века для работы с протоколом X11. Его код генерируется автоматически на основе XML-файла, описывающего протокол.Для сравнения, Xlib состоит из мрачного кода 80-х, почти не комментируемого и полного жестко закодированных вещей.
Лишь немногие способны разобраться в некоторых его закоулках, таких как интернационализация или реализация XKB. И весь его код синхронный .
Поясню для тех, кто еще не в курсе: X — это сетевой протокол, в котором вы должны отправить запрос (например, GET в HTTP), чтобы затем получить ответ. Xlib заставляет приложение ждать ответа на запрос, поэтому приложение блокируется до тех пор, пока X-сервер не отправит ответ. XCB не блокирует приложение, что позволяет отправить серию запросов, во время ожидания сделать что-то полезное, а затем получить ответы.
Представьте, что ваш браузер отправляет по одному запросу на веб-сервер и заставляет вас ждать отображения страницы, пока не загрузится последнее изображение.
В случае, когда X и все его клиенты расположены на одном компьютере, задержка невелика и незаметна, поэтому польза от асинхронности XCB невелика.
Однако в медленной сети прирост производительности может быть огромным, так как доказано Питером Харрисом путем переписывания xlsclients в XCB .
Одна из долгосрочных целей разработчиков XCB — окончательно избавиться от Xlib, чтобы увеличить скорость и сократить время отклика приложений X11. Для этого необходимо портировать множество библиотек, потому что почти ни одна из них (кроме Каир ) не поддерживает XCB. С моей точки зрения, сейчас это довольно бесполезное усилие.
Мир рабочего стола вверен проектам GNOME и KDE, то есть GTK+ и Qt. При этом ни один из этих наборов инструментов, похоже, не заинтересован в работе ни с XCB, ни с протоколом X. Скорее, они прилагают огромные усилия, чтобы обойти существующие ограничения и недостатки X, и все еще сидят на вершине кучи костылей и реализаций ошибочных стандартов проектирования.
Мне кажется, никто не хочет оглядываться на все эти уровни и смотреть, как их можно улучшить.
Они забрались слишком высоко, чтобы посмотреть вниз и увидеть, какими могут быть последствия.
Просвещение с его Английская футбольная лига был первым набором инструментов, имеющим бэкэнд XCB (благодаря работе Винсента Торри).
К сожалению, этот бэкэнд больше не поддерживается и никого не волнует. В последний раз, когда я это пробовал, он даже не скомпилировался.
Х12?
В вики Freedesktop есть страница под названием х12 , в котором перечислено все, что необходимо исправить.К сожалению, этот список только растёт, и никто не упоминает о работе над X12. С другой стороны, есть несколько человек, которые работают над ХКБ2 , вторая версия расширения «давайте-попробуем-еще раз-исправить-часть-протокола-клавиатуры-написана-23 года назад».
В целом, не похоже, что X12 появится в следующем десятилетии.
Альтернативы?
Есть ли у нас альтернатива Х? Есть Вейланд , но пока это совершенно бесполезно.А также есть ДиректФБ , но он плохо портируется.
На мой взгляд, кандидатов на замену Х пока нет. В любом случае, ни один из основных наборов инструментов не поддерживает такую альтернативу.
GTK+ когда-то поддерживал DirectFB, но, насколько мне известно, больше ничего не работает (как заметил Жослен Муэтт ).
Вот почему последние версии установщика Debian перешли на использование X для графической части (благодаря работе Сирила Брюлебуа).
Заключение
XCB существует уже более пяти лет, но мало кто ею интересуется.Насколько я вижу, никто не заинтересован в использовании протокола X, все просто пытаются инкапсулировать его с помощью какого-то высокоуровневого API, чтобы как можно быстрее перестать его видеть.
Это приводит к плохо написанным приложениям и наборам инструментов, полным уродливых хаков.
Все это также означает, что написание новых приложений и наборов инструментов на базе XCB должно быть очень интересным проектом, но потребуется много времени, чтобы разобраться, как обойти недостатки протокола X, привнесенные за эти годы предшественниками, включая Qt. и ГТК+.
Основные наборы инструментов мало что выиграют от возвращения в темные воды X. Я думаю, что большинство их разработчиков предпочли бы работать над красивыми 3D-эффектами на основе геолокации, чем переопределять лучшую структуру для всех.
В мире X слишком мало рабочей силы.
Нехватка сопровождающих X в Debian является простым следствием этой ситуации.
Конечно, есть очень компетентные и опытные разработчики X, в чем вы легко можете убедиться, прочитав блоги на Планета Фридесктоп (я не в счет).
К сожалению, их количества недостаточно, чтобы охватить весь спектр деятельности X: устройства ввода, графические устройства, спецификации новых расширений протоколов и так далее.
Сервер X — сравнительно недавняя разработка, и большинство разработчиков больше заинтересованы в работе над ним, чем над самим протоколом.
Это понятно.
Интересно, чем мы закончим со всем этим через несколько лет? К настоящему времени я варюсь в котле под названием X уже 3 года и чувствую, что рано или поздно все альтернативы KDE и GNOME вымрут. Время, когда можно было выбирать между десятком «современных» оконных менеджеров, прошло.
В конце концов, это может быть простой дарвинизм, примененный к компьютерному программному обеспечению.
Примечание переводчика: автор статьи — французский программист Жюльен Данжу, разработчик оконного менеджера Awesome. Оригинал статьи находится Здесь .
Это мой перевод. Я давно не занимался переводами, поэтому буду благодарен за исправления и разъяснения.
Теги: #настройка Linux #X11 #GNOME #kde #awesome
-
Обзор Ноутбука Toshiba Satellite T135D-S1324
19 Oct, 24
