LINUX.ORG.RU

Wayland — разъяснения от разработчиков KWin

 , ,


0

3

Дисклаймер. В связи с тем, что очень многие (почти все) здесь не понимают, зачем нужен Wayland, пишу в новости, благо есть источник, где кое-что разжёвано. Текст чуть-чуть подсократил, чтобы не захламлять.

Итак, приступим.

  1. В Wayland может быть реализована сетевая прозрачность.

    Это дело конкретного композитора. Всё дело в ошибочном понимании фразы «в Wayland нет сетевой прозрачности». Правильное понимание этой фразы таково: «спецификация Wayland не занимается сетевой прозрачностью и не определяет её». Композиторы могут быть выполнять локальную отрисовку, могут быть сервером и передавать картинку по сети (хоть на много машин одновременно), а могут делать и то и другое. Те, кто думают, что в Wayland сетевой прозрачности быть не может вообще, ошибаются.

  2. Сетевая прозрачность X11 не подходит для современных приложений.

    Она давно устарела, будучи сделанной с расчётом на то, что приложения используют простые команды для отображения содержимого окна, и эти команды можно отправлять по сети. Когда-то это было разумно, но современные приложения не используют X11 для рендеринга, они используют такие технологии как Cairo, Clutter, QPainter (Raster) или OpenGL. В этом случае X11 вынужден отправлять по сети готовую картинку, а для этой ситуации есть технологии, которые делают это гораздо лучше, чем X11. Сетевая прозрачность в X11 померла и так, без участия Wayland.

  3. X11-приложения будут поддерживаться.

    Никто не хочет ломать систему, переход на Wayland будет произведён если и только тогда, когда X11-only приложения будут в ней хорошо работать (через слой совместимости). Сетевую прозрачность X11, очевидно, тоже можно будет использовать.

  4. Сетевой прозрачности не место в оконной системе. Если вы хотите быстрой сетевой прозрачности, ей место в тулките виджетов.

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

  5. «Дистибутивы выкинут иксы, моё любимое X11-only приложение не заведётся!»

    Для этого уже есть слои совместимости (X11 приложения можно запускать из композитора Wayland). Поддержку X11 никто не выкинет из дистрибутивов, пока она будет востребована, даже Mac OS X всё ещё поддерживает X11 для совместимости. Постепенно количество X11-only приложений будет уменьшаться (переписывание, естественная смерть), и даже если из вашего дистрибутива поддержку X11 уберут, вы всегда сможете её собрать сами.

Прекратите повторять ошибочные утверждения.

P.S. Отвечу на вопрос «Зачем вообще нужен Wayland, давайте улучшать X11».

Такие (или аналогичные) изменения даже если были бы возможны в X, всё равно бы сломали X11 и дали несовместимый с ним X12. Без слоя совместимости обойтись невозможно, а сам X12 тоже был бы не сахар, так как писался бы с оглядкой на X11. И чем это было бы лучше того, что мы имеем с Wayland?

В основе X11 лежат архитектурные решения более чем двадцатилетней давности (см выше). Так делать уже не надо, очень много функциональности иксов перешло в тулкиты, ядро, D-Bus, и другие системы. Замену легче написать с нуля, которая делает только свою прямую работу, а не пытается объять всё.

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

★★★★★

Проверено: svu ()
Последнее исправление: cetjs2 (всего исправлений: 11)
Ответ на: комментарий от farafonoff

> Потому что остальное переделывать намного сложнее.

/facepalm

Лично я ненавижу иксы хотя бы за систему ввода текста (невозможно например использовать кнопку ctrl для переключения раскладки не теряя возможности использовать сочетания клавиш с ней).

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

И, да — ctrl _можно_ задействовать для переключения раскладки, не теряя возможности использовать хоткеи с ней. Домашнее задание: ознакомиться с механизмами обработки ввода в иксах и понять, каким образом этого достичь.

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

>И, да — ctrl _можно_ задействовать для переключения раскладки, не теряя возможности использовать хоткеи с ней.

Как? А то не хочется терять часть хоткеев, использующих Alt+Shift. Это, конечно, не Ctrl, но метод настройки должен же быть одинаковым.

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

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

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

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

Чо как маленький-то?

1. Слушаешь иксовые события ввода.
2. Ждёшь, пока появится последовательность KeyPress KeyRelease для ctrl, не разделенная другими вариантами.
3. Переключаешь раскладку.
4. ???
5. Профит.

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

https://bugs.freedesktop.org/show_bug.cgi?id=865

Собственно вот этот баг. Патч решает проблему для двухкнопочной переключалки (ctrl+shift) но не работает для однокнопочной (ctrl). Там пишут что проблема в спецификации иксовых библиотек.

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

Пока костыль не замедляет систему и не бажит — это вполне себе решение. А если его ещё документировать…

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

Вообще, у меня последние пару лет на линуксе было 2 независимые переключалки раскладки, одна иксовая (en-ru), вторая UIMовая (en-jp), работало же. Хотя некоторые DE пытались их объединить в SCIM/ibus.
Если в иксы встроено что-то неполноценное — никто не запрещает игнорировать это и использовать сторонний софт.

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

Ты тролль. Только что проверил xev, если на ctrl навешано переключение, то иксы посылают не Control_L, а ISO_Next_Group, а значит твое решение просто не сработает.

Вопрос все еще открыт - с 2004 года.

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

Костыль - понятие архитектурное. Он либо есть либо его нету. Проблема упирается в решения 13-летней давности.

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

Я им и не пользуюсь (только по этой причине), я пользуюсь капсом, а там другая проблема - иногда включается сам капслок при переключении, и выключить его можно только через shift+caps.

Вообще идея написать свою переключалку интересна, надо будет попробовать.

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

Да ну рассказывай сказки, я кэпсом переключаю уже пару лет.

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

Я знаю, по дефолту оно как раз на левом альте. Просто мне так удобно, я не давлю шифт, когда давлю кэпс :)

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

> Ты тролль. Только что проверил xev, если на ctrl навешано переключение, то иксы посылают не Control_L, а ISO_Next_Group, а значит твое решение просто не сработает.

Ты просто глуп. Смирись.

Вопрос все еще открыт - с 2004 года.

Плохому танцору...

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

> Ты понимаешь что это костыль - при наличии иксовой переключалки делать свою.

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

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

> Я видел баг в багтрекере иксов, и я знаю что это не работает.

Ты видел баг в багтрекере!!! О мой бог, теперь мы будем звать тебя Свидетель Бага!

Я думаю когда к вейланду приделают переключалку, она учтет проблемы иксовой.

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

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

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

Иксы занимают странное промежуточное положение. Там есть ввод с клавиатуры и вывод графики, но нету транспорта звука, есть какое-то ipc, но помимо него запилили еще и dbus. Я думаю определенно стоит разобраться кто какие функции должен выполнять. Понятно конечно, что звука на компьютерах небыло 20 лет назад когда делали иксы, но сейчас колонки такая же неотъемлемая часть рабочего места как монитор и клавиатура.

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

Вот с этого и стоило бы начать: с разработки адекватной сеансовой шины, не такой угребищной как dbus, и не привязанной к иксам. И достаточно универсальной, чтобы поверх неё пускать любые фичи, необходимые для сеанса: и звук, и коннект к графическому серверу, и т.п.

А не заниматься решением несуществующих проблем.

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

Возможно они и хотят отделить графику от IPC, а IPC повесить на dbus. для звука в «десктопных» дистрах есть пульсаудио. Сетевую прозрачность убунтовцы впилят в гтк, если захотят, и потом можно будет собрать все это в одну кучу и получится юникс-вейная сетевая прозрачность :)

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

Значит надо переходить на Plan9. :)
Canonical: Plan9 с человеческим лицом.

ls-h ★★★★★
()
Ответ на: комментарий от farafonoff

Дело в том, что ввод надо пробрасывать всегда, а вот звук — далеко не всегда, напротив, иногда надо, чтобы звук то как раз играл, где играет.

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

Ввод тоже иногда можно бы не пробрасывать. Иногда по vnc «подглядываю» за администрируемым компом. В виндовом рдп наболевшем можно звук пробрасывать, а можно оставлять. Нельзя только подглядывать, для этого нужен радмин или рдп.

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

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

Я вообще не понимаю людей, сравнивающих VNC и X11, ибо тёплое и зелёное, поэтому даже и говорить ничего не буду

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

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

Для этого надо отделить рисовалку графики от менеджера шины сообщений. Т.е. пойти по пути фотона и микроядра.

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

А еще приложение должно корректно обрабатывать отваливание того и другого. Вопрос как приложение обработает отваливание рисовалки?

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

> Вопрос как приложение обработает отваливание рисовалки?

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

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

> Особенно круто будет со всякими shm, drm и прочими расширениями.

Ну значит клиент пересоздаст соответствующие объекты по запросу сервера на переконфигурацию рисовалки. Делов-то.

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