Три проблемы Вайланда, как фиксить?

Линукс как свободная система, сделанная по принципу базара, по идее должна бы поощрять эксперименты и частные прикладные решения, которые свободно конкурируют между собой.

Этакий software toolbox в графической реинкарнации.

Иксы при всех архитектурных изъянах худо-бедно с этой задачей справлялись.

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

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

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

Есть обычная проблема при сравнении хреней Х и У по каким-то заранее зафиксированным признакам. Вещи могут работать иначе, не всегда это вообще сравнимо.

Когда сравнивают вяленый с иксами, обычно сравнивают вяленый со сложившимся укладом вещей. А в худшем случае вяленый (как протокол) со сложившимся укладом вещей. Но иксы это тоже протокол. Достаточно убогий, тоже с расширениями, которых может и не быть. Например может не быть xkb :) Может не быть xrandr, xinerama, composite, xdamage, xtest. Просто все живут на xorg, в котором это все есть. Это какие-то стабильные правила игры, к которым все привыкли, и считают должным. Но в абстрактной ситуации это возможно. У нас мог бы быть XNIHGOrg, XYZ-Server и еще какая-нибудь хрень. Просто всё устаканилось и исдохло десятилетия назад.

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

Т.е. ситуация с libmutter, kwin, wlroots это как если бы существовали гипотетические XNIHOrg, XYZ-Server и xorg.

С практической точки зрения рано или поздно набор API придёт к общему знаменателю. Или через расширение протокола, или через какой-нибудь libwayland-ext-hal-xyz.

В линаксе все очень очень плохо с каким-то одним стандартным путем решения проблем. Одной больше - без разницы ))

Я так скажу. Достаточно просто разок зайти на канал Libera Chat и позадавать вопросы создателям того или иного проекта. Практика показала, что интерес к их поделкам и нормальный тон, положительно решают в получении всех интересующих тебя ответов. wandrien пишет только малую часть. Он читал спецификацию протокола, а реализация. Это… Это дичь!

Там хотя бы звук на ровном месте не заикается и тиринга нет.

Ахах. Только ты в режим энерогосбережения - привет тиринг. Только ты начал слушать радио с инета и включил всякие power save wifi - привет заикания. На сертифицированном железе известной марки.

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

Только ты начал слушать радио с инета и включил всякие power save wifi - привет заикания

Что-то глупее придумать не мог? Ну можно ещё HDD загрузить по максимуму в 10 потоков. Наверняка не сможет аудиоплеер без заиканий.

Поинт не в этом же был.

Каштан.

Пользователи отключить PRIMARY selection на ноутах не могут без чудовищных костылей, а виноват я.

Да, ибо у вас какая-то иррациональная ненависть к X11. PRIMARY selection реализован в тулкитах, обвиняйте их что не сделали нормальную настройку.

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

Тулкиты криворукие, так давайте ещё GUI сервер в придачу поломаем. Гении архитектуры.

У меня, кстати, именно что была мысль запатчить подобным образом иксы, но не отправлять ничего в апстрим (такое конечно бы не приняли), а просто патчик для страждущих на ЛОРе опубликовать

Зачем так страдать если проблема решается парой переменных окружения?

Искать все эти методы отключения PRIMARY в GTK+2, GTK+3, GTK+4, Qt 4, Qt 5, Qt 6, в некоторых из которых это вообще неотключаемо… врагу не посоветуешь.

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

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

А что под вялендом мешает тебе в твоих же приложениях сделать простой протокол обмена поверх готовых средств IPC? Или других средств IPC помимо встроенных в X11 не придумали?

Вообще, интересно то, что ещё 20 лет назад, когда иксы цвели и пахли, в КДЕ 2 внутрях был реализован свой собственный IPC DCOP. Т.е. когда вяленда ещё и в проекте не было, иксовый IPC был настолько говном, что чисто иксовое DE предпочитало навелосипедить свой чем пользоваться существующим. Теперь, в 2021, когда есть стандартный dbus, нужно срочно откопать X11 IPC и пользоваться им.

Что ж ты к дисплейному серверу через дбас не коннектишься, умник))

Зачем, если есть готовый протокол? Вопрос а том, зачем пилить свой протокол поверх говённого ipc, когда есть нормальные ipc?

Зачем же тебе нужны какие-то ipc, если есть «готовый протокол»?

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

Вообще, интересно то, что ещё 20 лет назад, когда иксы цвели и пахли, в КДЕ 2 внутрях был реализован свой собственный IPC DCOP. Т.е. когда вяленда ещё и в проекте не было, иксовый IPC был настолько говном,

А вот дети это прочтут и подумают, что так и было.

В протоколе X11 нет IPC. Есть отдельный протокол ICE (Inter-Client Exchange) [1], который был стандартизован в рамках X Consortium

в КДЕ 2 внутрях был реализован свой собственный IPC DCOP.

Протокол DCOP не свой собственный, а был основан на том же ICE [2]. На протоколе ICE основан X Session Management Protocol [3], который точно был до последнего в KDE. Даже сейчас, по-моему, KDE Activities поддерживает XSMP.

[1] https://www.x.org/releases/X11R7.6/doc/libICE/ice.html

[2] https://api.kde.org/3.5-api/kdelibs-apidocs/dcop/html/index.html

[3] https://www.x.org/releases/X11R7.7/doc/libSM/xsmp.html

В протоколе X11 нет IPC.

https://tronche.com/gui/x/xlib/window-information/properties-and-atoms.html

https://tronche.com/gui/x/xlib/window-information/properties-and-atoms.html

Это совершенно другая вещь. ICCCM совершенно другие задачи решает. Это система договоренностей. В протоколе X11 есть свойства окон (properties), которые можно создавать, что-то им присваивать, есть возможность посылать клиентские сообщения, но это все только механизмы, а не политика. ICCCM - это как раз создание некоторых правил. И эти договоренности затрагивают только определенные вещи, такие как взаимодействие с оконным менеджером, буферы обмена и др. https://en.wikipedia.org/wiki/Inter-Client_Communication_Conventions_Manual

Вот тут кратко различие описано: сначала про ICCCM, потом про ICE:

https://en.wikipedia.org/wiki/X_Window_System_protocols_and_architecture#Inte...

ICE - это что-то типа транспортного протокола для реализации протоколов межклинетского взаимодействия. Тоже, в общем-то механизм, а не политика. Вот DCOP уже был политикой, но GNOME носом воротили и игрались в CORBA.

https://tronche.com/gui/x/xlib/window-information/properties-and-atoms.html

И добавлю еще. Не буду добавлять в предыдущее сообщение. Да, можно придумать такую хреномуть, чтобы фигачить что-то через атомы. Кстати, в том же KDE до DCOP был KWMcom, который через атомы позволял обмениваться. Но что там через атомы напередаешь? Так, какие-то мелкие задачи для KDE решали, и все. Поэтому и отказались от этого механизма и стали делать на базе ICE, который не часть X11 (как протокола).

И чем это не механизм межпроцессного обмена?

Поверх него можно пускать любые прикладные протоколы. Тот же буфер обмена по ctrl+c, cttl+v не более чем такой прикладной протокол, договоренность.

Но что там через атомы напередаешь?

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

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

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

Через что его еще делать, через dbus или велосипедить свой костыль на юникс-сокетах? А можно еще отправлять почтовых голубей…..

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

Не, я не буду спорить с тем, что для решения десктопных задач этого оказалось пока достаточно. Да и по сети работает по канонам сетевой прозрачности, а через dbus нельзя. Главная проблема всегда в том, чтобы выработать договоренности и чтобы все согласились им следовать. Я считаю, что ICCCM/EWMH очень большое завоевание. Не в смысле что это чудо инженерной мысли, а в организационном смысле. Практически все следуют этим соглашениям, написана куча оконных менеджеров. А сейчас мы видим, что стандартизация стала очень тяжелым делом. Каждый свою песочницу делает.

Я вот писал нотификацию для Emacs Jabber, когда приходит сообщение через свойство WM_HINTS - так оно практически везде работает. [emacs] urgent-hint для окна емакса. (комментарий)

Например может не быть xkb :) Может не быть xrandr, xinerama, composite, xdamage, xtest. Просто все живут на xorg, в котором это все есть.

В таких условиях современные тулкиты в принципе могут работать. За все не скажу, но вот GTK, Qt могут работать и без Render, без MIT-SHM, без Composite, без XTEST и т. д. Это на уровне тулкита решается. Но есть приложения, которые хотят Randr. Разумеется, xrandr не заработает, но раз X server не умеет в RandR, то и делать там нечего. Это можно проверить, отключив расширения на Xephyr:

$ Xephyr :1

$ DISPLAY=:1 xdpyinfo
[...]
number of extensions:    23
    BIG-REQUESTS
    Composite
    DAMAGE
    DOUBLE-BUFFER
    GLX
    Generic Event Extension
    MIT-SCREEN-SAVER
    MIT-SHM
    Present
    RANDR
    RECORD
    RENDER
    SECURITY
    SHAPE
    SYNC
    X-Resource
    XC-MISC
    XFIXES
    XINERAMA
    XInputExtension
    XKEYBOARD
    XTEST
    XVideo
[...]

$ Xephyr -extension COMPOSITE -extension RENDER -extension XTEST -extension MIT-SHM -extension DAMAGE -extension RANDR -extension GLX -extension XFIXES :1

$ DISPLAY=:1 xdpyinfo
[...]
number of extensions:    13
    BIG-REQUESTS
    DOUBLE-BUFFER
    Generic Event Extension
    MIT-SCREEN-SAVER
    Present
    SECURITY
    SHAPE
    SYNC
    X-Resource
    XC-MISC
    XInputExtension
    XKEYBOARD
    XVideo
[...]

Работают:

$ DISPLAY=:1 inkscape
$ DISPLAY=:1 firefox-esr
$ DISPLAY=:1 qpdfview
$ DISPLAY=:1 qimgv

Отсутствие Render, MIT-SHM для них не помеха. Автоматом переходят на программную отрисовку. Qt все равно Render не использует, а GTK использует, если он есть, ну а если нет, то вот - тоже работает. MIT-SHM отсутствует - закидываем через PutImage через сокет, а не через Shared Memory.

Не работают приложения, которые не могут работать без расшиений по своему смыслу, хотя считаю, что у xdotool есть возможность выполнять большую часть функцию без XTEST. Зачем он с порога отказывается запускаться, я не знаю (UPD: А, не, вру, функции, которые не требут XTESTб работают).

$ DISPLAY=:1 xrandr
RandR extension missing
$
$ DISPLAY=:1 xdotool type a
Warning: XTEST extension unavailable on '(null)'. Some functionality may be disabled; See 'man xdotool' for more info.
Xlib:  extension "XTEST" missing on display ":1".
Xlib:  extension "XTEST" missing on display ":1".
$

В целом не так все плохо. Есть даже шанс, что на древних серверах будет работать. :)

За все не скажу, но вот GTK, Qt могут работать и без Render, без MIT-SHM, без Composite, без XTEST и т. д.

Я тут даже хз что сказать. Ну разве то что GTK и Qt могут и без иксов работать ))

глупее придумать не мог? Ну можно ещё HDD загрузить по максимуму в 10 потоков

боль hdd-дебила бесценна

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

Задача: Двум клиентам дисплейного сервера нужно обменяться данными.

Решение:

Логичный вывод из этого - пилить свой протокол поверх дбаз.

И в самом деле логичный. А еще можно слать пакеты почтовыми голубями. Или оставлять записки в укромном месте под памятником Ленина.

В протоколе X11 нет IPC.

Я тебе конечно верю.

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

Протокол DCOP не свой собственный, а был основан на том же ICE [2]

Принимается. Хотя ты сам себе противоречишь, если он поддерживается одной системой, то он собственный, неважно на чём он основан. Тем не менее, видимо, голый ICE или что там ещё им не подходил и впоследствии они перешли на дбаз. Соответственно суть моего вопроса не меняется, зачем колхозить что-то поверх иксов, если иксы неуниверсальный и явно сворачиваются, а то что они могут предложить даже 20 лет назад было не фонтан?

Задача: Двум клиентам дисплейного сервера нужно обменяться данными.

Хорошо, вот тебе другая задача: двум веббраузерам (работающим локально под одним пользователем), нужно обменяться данными. Какой сделаешь «логичный» вывод? «Раз вебраузеры то пусть обмениваются через вебсайт»?

То что ты обозвал 2 программы клиентами дисплейного сервера ничего не поменяло в сути задачи, это всё равно 2 программы. Выбор бэкенда для протокола обмена делается по общим правилам. Если ты знаешь, что есть нормальный dbus, которым все пользуются и есть хрень в иксах, которой не пользуются и которая сдохнет вместе с иксами, а может и в каком-нибудь совместимом сервере не поддерживается изначально, то зачем выбирать иксы?

Если ты знаешь, что есть нормальный dbus, которым все пользуются

Срочно донеси эту новость до авторов следующих протоколов:

• https://wayland.app/protocols/primary-selection-unstable-v1
• https://wayland.app/protocols/kde-idle
• https://wayland.app/protocols/kde-plasma-window-management

А то они не знают, что «все пользуются dbus» и зачем-то шлют данные через сокет дисплейного сервера.

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

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

Итак, какие у нас есть варианты?

1. Запилить 2 расширения дисплейного протокола, «я хочу работать рассыльщиком писем» и «я хочу составить письмо» и потом ныть в багтрекерах каждого DS чтоб этот протокол поддержали.
2. Запилить собственный протокол поверх присутствующего в системе дженерик IPC
3. Запилить собственный протокол поверх запиханного в дисплейный протокол дженерик IPC.

Первый вариант - это клинический идиотизм, никто такое делать не будет и никто такое делать не предлагает, я не знаю с чего ты вообще решил что так надо. Мало того что клиент и сервер нашего протокола должны его поддерживать, но ещё и DS.

Какие есть преимущества у варианта 2? Ну, первое - это простота реализации DS. Собственно ради этого вейланд и затевался, чтоб можно было наколхозить свой дисплейсервер не делая 100500 необходимых фич внутри него. Второе - этим протоколом смогут пользоваться негуёвые приложухи. Третье - он будет работать и вообще в отсутствие дисплейсервера, может же наш рассыльщик писем общаться с пользователем через вебморду.

Какие преимущества у варианта 3? Ровно одно: сетевая прозрачность. Если реализовать через встроенный в дисплейный сервер IPC, то программа, работающая на машине 1 сможет воспользоваться услугами рассыльщика писем работающего на машине 2 через дисплейсервер на машине 3 и всё это будет выглядеть для юзера сидящего за машиной 3 как будто так и надо.

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

Давай возьмём реально прикладную задачу.

Давай.

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

Запилить 2 расширения дисплейного протокола, «я хочу работать рассыльщиком писем» и «я хочу составить письмо» и потом ныть в багтрекерах каждого DS чтоб этот протокол поддержали. […] Первый вариант - это клинический идиотизм

Хорошо, что ты признаешь, что ворох расширений протокола вейланда - клинический идиотизм.

Какие преимущества у варианта 3? Ровно одно: сетевая прозрачность.

Неверно. Сетевая прозрачность тут если где и вылазит, то лишь как потенциально полезный побочный эффект. Главное же преимущество здесь архитектурное. Всё, что относится к GUI, работает на сокете, который относится к GUI.

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

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

Бро, я по ссылкам твоим не ходил

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

Тем не менее, видимо, голый ICE или что там ещё им не подходил и впоследствии они перешли на дбаз.

Голый ICE, в общем-то, это бинарный протокол, который заведует авторизацией, передачей, приемом данных, разъединением. В общем-то, субстрат такой, а DCOP использовал это все, чтобы уже смысл в передаваемые данные добавить. И надо было добавить IPC не только к графическим программам. Если использовать те же атомы, то надо становиться клиентом X Server, соединяться с ним. Ну, то есть «политику на готовый механизм», смысловой слой. dbus я бы сравнивал с DCOP, а не с ICE все же, да.

Havoc Pennington рассказывал почему и что. Столкнулись с проблемой, что разные экосистемы начали разными путями идти. GNOME - CORBA (весьма тяжеловесный вариант), KDE - DCOP. Поэтому он решил их как бы подружить, активно разговаривал и с теми, и с теми, чтобы засунуть в dbus необходимые вещи и чуть развить (как он это видел). dbus как вариант компромисса им прокатил, его взяли в KDE, его взяли в GNOME.

Вот, кстати: https://dbus.freedesktop.org/doc/dbus-faq.html

Соответственно суть моего вопроса не меняется, зачем колхозить что-то поверх иксов, если иксы неуниверсальный и явно сворачиваются, а то что они могут предложить даже 20 лет назад было не фонтан?

Да многие иксовые механизмы собирались заново делать в протоколе Wayland. Об этом автор Wayland заявлял. Переизобретением заниматься. Насколько я могу судить, там таки это делают, но я всех масштабов не знаю, не слишком слежу. Пока до меня доносится, что у GNOME свои бирюльки, wlroots свои бирюльки.

Автор Wayland, Kristian Høgsberg, пояснял:

https://lists.freedesktop.org/archives/wayland-devel/2010-November/000270.html

I am interested in what will replace things like

- ICCCM/EWMH, where a desktop environment can enumerate and control the display clients - the things that root and application window properties are used for under X - some of the things that selections are used for under X (poor man's system-wide lock manager) - Accessibility knobs («AccessX features») - Window states (Iconify, deiconify, «I'm a dock», fullscreen, and such)

Up to toolkit, wayland is about compositing buffer and sending input. I would advice to leave wayland out of this business and to encourage some common platform on freedesktop for window properties valid accross toolkits (gtk, qt, ...)

No, this is actually something Wayland has to handle as well. You can't just implement these protocols in the toolkit if there's nobody to talk to. Wayland combines the display server, the window manager and the compositor in one process and thus, must provide an alternative for the functionality provided by these processes and protocols layered on top of X mechanisms. This means that the Wayland protocol ends up being a mix of (the useful pieces of) X protocol, ICCCM, EWMH, XDnD.

[...]

A great contribution would be a writeup that provides an overview of the functionality in the X protocol, ICCCM, EWMH, Xdnd, xsettings specs and then a classification into «not necessary», «already done», «needs wayland support», or «can be done over dbus or such».

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

Бессмысленная фраза. Давай конкретнее. Чтоб было легче даю подсказку: в твоём описании не должны использоваться слова «окно», «виджет», «дисплейный сервер». Это прикладуха, соответственно и задача должна быть прикладная, формулироваться в терминах предметной области. Если это текстовой редактор, у тебя должен быть текст, параграфы, строки, символы.

Неверно. Сетевая прозрачность тут если где и вылазит, то лишь как потенциально полезный побочный эффект. Главное же преимущество здесь архитектурное. Всё, что относится к GUI, работает на сокете, который относится к GUI.

– Раббе, а почему все евреи должны обрезание делать? – Во-первых, это красиво.

Так вот, «красиво» - это не во-первых. Во-первых именно сетевая прозрачность. Вообще вот тебе rule of thumb: если видишь в x window system какое-то говно и не очень понимаешь зачем оно здесь, смело предполагай что ради сетевой прозрачности. Ради неё всё и писалось.

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

Ну, в общем-то так всегда и происхродит. Браузер качает данные по одному сокету, а гуйню рисует по-другому. Или не браузер, а curl какой-нибудь.

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

Уж если это не «реально прикладная задача», то тогда я даже не знаю, что.

Да я уже заметил, что ты не различаешь. Выше я тебе объяснил.

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

No, this is actually something Wayland has to handle as well. You can’t just implement these protocols in the toolkit if there’s nobody to talk to…

A great contribution would be a writeup that provides an overview of the functionality in the X protocol, ICCCM, EWMH, Xdnd, xsettings specs and then a classification into «not necessary», «already done», «needs wayland support», or «can be done over dbus or such».

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

Вообще, надо понимать, что вяленд в 2010м и сейчас это 2 большие разницы. Есть такая мудрость: не спеши выполнять приказ, авось отменят. Сейчас во многом такое происходит, то что раньше казалось необходимым, потому что активно использовалось в иксах, вдруг оказывается не то что бы очень нужным в реальной работе. Можно описать это как «авторы вяленда обманули, обещали всё вернуть, но не вернули», однако в реальности выходит именно так, работа идёт не по копированию механизмов из иксов, а по направлению "как бы вот эту пользовательскую фичу можно было бы минимальными усилиями реализовать. И вообще стоит ли она того чтоб париться.

Бессмысленная фраза. Давай конкретнее. Чтоб было легче даю подсказку: в твоём описании не должны использоваться слова «окно», «виджет», «дисплейный сервер». Это прикладуха, соответственно и задача должна быть прикладная, формулироваться в терминах предметной области. Если это текстовой редактор, у тебя должен быть текст, параграфы, строки, символы.

Специально для одарённых:

Согласовать ВИЗУАЛЬНОЕ состояние двух ОКОН приложения, которые рисуется разными ПРОЦЕССАМИ.

Так хорошо видно?

Да я уже заметил, что ты не различаешь. Выше я тебе объяснил. Вот, всякие идеи типа «нужен хоткей, который позволит обходить контролы в обратном по отношению к табу порядке» или "закрепить окно в положении «поверх всех» - это не прикладуха ни разу, это DE-дрочество.

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

как бы вот эту пользовательскую фичу можно было бы минимальными усилиями реализовать

«Минимальными усилиями». xD

Дарахой, самым минимальным усилием было бы портануть атомы и свойства на вяленд, чтобы гонять поверх них NETWM.

ВСЁ.

Поднажмите, господа. Еще страниц 15 — и можно просить Шамана добавить тему в список эпик тредов ЛОРа.

Согласовать ВИЗУАЛЬНОЕ состояние двух ОКОН приложения, которые рисуется разными ПРОЦЕССАМИ.

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

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

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

Различие в данном случае принципиально. Если ты собираешься делать протокол для прикладухи - почёт тебе и уважение, ты - человек решающий нормальные, полезные задачи. А если ты собрался писать овцу, которая по заголовкам окон ходит, то твои проблемы вообще мало кого интересуют. Поэтому я настаиваю на том, чтоб ты предложил нормальную прикладную задачу. Если ты сам видишь, что для нормальных прикладных задач синхронизация средствами DS не нужна, ну так какие тогда проблемы вообще?

A great contribution would be a writeup that provides an overview of the functionality in the X protocol, ICCCM, EWMH, Xdnd, xsettings specs and then a classification into «not necessary», «already done», «needs wayland support», or «can be done over dbus or such».

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

Различие в данном случае принципиально. Если ты собираешься делать протокол для прикладухи - почёт тебе и уважение, ты - человек решающий нормальные, полезные задачи. А если ты собрался писать овцу, которая по заголовкам окон ходит, то твои проблемы вообще мало кого интересуют. Поэтому я настаиваю на том, чтоб ты предложил нормальную прикладную задачу. Если ты сам видишь, что для нормальных прикладных задач синхронизация средствами DS не нужна, ну так какие тогда проблемы вообще?

Ты дурной что ли?

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

А то что ты описал, это мало того что не прикладуха,

То есть логика прикладного кода -это не прикладуха. Ооооок… Дальше веселее:

это вообще вещь, не требующая нормального протокола.

Действительно, чо это я. Нормальный протокол отломали криворукие дебилы, не умеющие в архитектуру системных компонентов, так что можно просто теперь сувать данные в dconf или в файлик в /tmp, или в dbus, или почтыовыми голубями посылать.

Сформулирую еще раз другими словами, может так дойдёт.

Под вялендом одно приложение может другому послать кастомное событие в окно?

Вот в винде может.

Под иксами может.

А в вяленде?

Винду наверное дураки делали, понимаю.

Поехалы дальше.

Есть приложение. Есть разработчик. Разработчику нужно это приложение автоматизированно тестировать.

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

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

В случае вейланда для этой задачи, видимо, предполагается форкнуть GNOME Shell.

А самый позор и мякотка в этой ситуации это создание сторонними разработчиками пакетов патченных иксов

А может, это вопрос к людям, которых ты упорно называешь «разработчиками иксов» (когда надо сослаться на то, что даже им иксы не нужны)? Почему они не вольют эти патчи в апстрим?

Столкнулись с проблемой, что разные экосистемы начали разными путями идти. […] Поэтому он решил их как бы подружить

Имхо, но лучше было бы идти своими путями. Это не только этого специфического случая касается.

Лучше иметь две несовместимые, но воплощающие целостную архитектурную идею GnomeOS и KDE OS, чем ворох компромисных решений, вынужденных ограничивать себя вопросами совместимости с принципиально другим проектом.

А dbus очень сильно оверинженернули и при этом не дали простых инструментов для задач автоматизации-интеграции поверх него.

По итогу он остался глубоко внутренней прослойкой. DCOP как-то человечнее был.

Ты дурной что ли?

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

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

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

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

Винду наверное дураки делали, понимаю.

Ну, вообще, если грубо то да. Не то что бы реально дураки, но делали в 80х - начале 90х не очень понимая что нужно, а потом вот годами колхозят костыли чтоб это как-то работало. Ну ты слышал наверное, что если сидящая в подпапке Program files программа хочет писать в собственную папку, то её не обламывают по отсутствию прав, а вместо этого перенаправляют запросы в другую. Конкретно твой юзкейс, когда-то, например, можно было послать WM_GETTEXT полю с паролем чужого окна и таким образом украсть пароль, потом это прикрыли чтоб парольные окна не отдавали. Так что в общем да, то что было в винде и под иксами - это была крупная архитектурная ошибка, решето.

Есть приложение. Есть разработчик. Разработчику нужно это приложение автоматизированно тестировать.

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

Чем подобная штука хороша? Да тем, что можно нормально и удобно отлаживать запущеную для отладки программу и при этом не оставлять такую же возможность для запущенной из контейнера игрульки.

Правда, есть одна проблема: с точки зрения вяленда никаких контролов в окне нет, только прямоугольник окна и точка куда посылать сообщения типа «кликнули по таким координатам». Если захочется чтоб тесты переживали небольшую смену лэйаута придётся либо пилить обнаружение кнопок визуально или же делать отладочный интерфейс на уровне тулкита. Или даже отладочный интерфейс на уровне команд бизнес логики. Но для таких интерфейсов нет никакого смысла сидеть в DS.

Ну, первое - это простота реализации DS. Собственно ради этого вейланд и затевался, чтоб можно было наколхозить свой дисплейсервер не делая 100500 необходимых фич внутри него.

Больше зоопарка богу зоопарка.

для чего вам этот wayland если X11 прекрасно справляется с задачами? просто используйте X11 и всё - никаких проблем не будет.

просто используйте X11 и всё - никаких проблем не будет.

сравнивая с виндой 10-11 x11 не годный ниначто и «отзывчивость» на уровне WindowsXP

в x11 альтаб и переключение рабочих столов занимает 15-30 кадров

в x11 хоткеи в десктопе отстают как минимум на 1 кадр

в x11 тиринг всего чего только возможно

в x11 кривущая тормозная прокрутка(текста/в браузерах) которая отстает на 15-30 кадров

в x11 очень кривой захват экрана кторый жрет в 2-5 раз больше ресурсов чем должен (сравнивая с виндой)

…

в Вайланде UI идеально отзывчивый и в тыщу раз приятнее работать чем в x11, единственные проблемы в Вайланде что меня интересуют я описал в первом посте темы, и еще захват видео в Вайланде тоже сломан(еще более тормознутый чем в x11) (хотя обещали EGL и захват прямо с ГПУ)

такбы пользовался Вайландом но вышеперечисленные проблемы вайланда очень критичные (даже один поломанный буфер обмена через 10 минут работы в вайланде уже непозволяет пользоваться вайландом полноценно)

сравнивая с виндой 10-11

Так и запишем: Wayland для латентных виндузятников.

Тред можно закрывать.

Meta+Space

чур меня!

ЗЫ поглаживая CapsLock