Wayland готов для десктопа?

А через сколько лет ждать решения проблем с X11/Xorg?

Никогда, судя по всему? Но как любят говорить фанаты Wayland, Xorg мёртвый.

К слову, я целиком и полностью согласен, что Xorg сосёт. Вообще ноль претензий. Проблема с Wayland в том, что он добавляет вагон проблем, которые потом по 10 лет героически исправляются через бесконечное дрочилово в комментах на Freedesktop.org. Типа к черновику протокола для изменения координат окон выкатили претензии, что он не будет работать с VR шлемами, где сферические координаты. Да, я серьёзно.

Основная проблема Wayland – дизайн комитетом, где никто не отвечает ни за что, но у всех есть мнение. Зато когда перцы из Valve решили обойти это и сделали свой репозитарий с протоколами, всем порвало жопу и сразу же дело зашевелилось.

Типа к черновику протокола для изменения координат окон выкатили претензии, что он не будет работать с VR шлемами, где сферические координаты. Да, я серьёзно.

ИЧСХ, они правы.

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

Типа к черновику протокола для изменения координат окон выкатили претензии, что он не будет работать с VR шлемами, где сферические координаты. Да, я серьёзно.

ИЧСХ, они правы.

Нет. VR – слишком специализированная штука, для неё в любом случае требуется специализированное решение. Требовать от какого-нибудь KDE поддержку VR будет достаточно глупо.

Забавно то, что VR мешают клиентские декорации с тенями и закруглениями, а в GTK их отключать всё равно не хотят. Также клиентские декорации мешают тайловым WM.

Сэндбоксинг в Wayland – фикция. Он просто всё портит, но ни разу не помогает от настоящих зловредов. Банальный пример: форкбомба с полноэкранным окном в каждом экземпляре. Удачи это убить!

cgroups

Применений много. Банальный вариант: открыть firefox с документацией в виде фрейма в Emacs.

Ну и костылище.

Что именно проклятого в XEmbed кроме того что разрабы Wayland не осилили?

Он никогда нормально не работал и его единственное применение было в tabbed и трей-иконках. И то и другое работало отвратительно.

С чего бы оно фейлило-то? Я не представляю сценария, при котором восстановить геометрию и координаты окна могло вообще сфейлить. Разве что если в монитор не влезает, но это очень странный сценарий.

Ну вот видишь, ты не знаешь деталей. Как и остальные иксофанатики.

Применений много. Банальный вариант: открыть firefox с документацией в виде фрейма в Emacs.

Ну и костылище.

Вызывать одну программу из другой – костылище. Так и запишем.

Что именно проклятого в XEmbed кроме того что разрабы Wayland не осилили?

Он никогда нормально не работал и его единственное применение было в tabbed и трей-иконках.

У меня работает нормально.

С чего бы оно фейлило-то? Я не представляю сценария, при котором восстановить геометрию и координаты окна могло вообще сфейлить. Разве что если в монитор не влезает, но это очень странный сценарий.

Ну вот видишь, ты не знаешь деталей. Как и остальные иксофанатики.

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

Сэндбоксинг в Wayland – фикция. Он просто всё портит, но ни разу не помогает от настоящих зловредов. Банальный пример: форкбомба с полноэкранным окном в каждом экземпляре. Удачи это убить!

cgroups

Сейчас во всех дистрах одна группа на сеанс пользователя.

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

Пост классный, а этот ваш вяленый для десктопа не готов.

Такие дела, комрады и комрадихи. 😉😎

xembed

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

ekekeke

Пост классный, а этот ваш вяленый для десктопа не готов.

Ну вот смотри, что я вчера сделал с Wayland:

1. Созвонился с коллегами, экраны пошарил, поговорили

2. Программу программировал

3. Фильм посмотрел

4. В Kingdom Cum поиграл

Где не готов-то?

Ты не понимаешь, это всё не нужно, нужно встраивать окошки одной программы в другую и автоматически тестировать гуй одной программы при помощи другой.

Самое смешное что в Wayland это тоже есть:

https://wayland.app/protocols/xdg-foreign-unstable-v2

Странно было бы такие базовые функции не уметь. Но только не для вялого, где показать кино это уже достижение. С особой гордостью вялоеды шарят экран стараясь не дышать. Пользователи нормальных десктопных ОС смотрят на эти потуги в недоумении.

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

Полистал тред, увидел следующие проблемы вяленда: невозможность всунуть фаерфокс в емакс, неспособность на горячую подхватить проектор с D-SUB, корявую работу с VRR-устройствами.

Если это всё, то мне, пожалуйста, бокал шампанского.

Firefox в емакс вычеркивай, нашли что такое можно.

И пива!

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

Нету.

In order for a client A to get a reference of a surface of client B, client B must first export its surface using xdg_exporter.export_toplevel. Upon doing this, client B will receive a handle (a unique string) that it may share with client A in some way (for example D-Bus). After client A has received the handle from client B, it may use xdg_importer.import_toplevel to create a reference to the surface client B just exported. See the corresponding requests for details.

Читай внимательнее. Это требует специальных ухищрений на стороне дочернего процесса.

Читай внимательнее. Это требует специальных ухищрений на стороне дочернего процесса.

Так и xembed требует: https://specifications.freedesktop.org/xembed-spec/0.5/messages.html

Не знаю, о каких достижениях, гордости и старании не дышать речь.

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

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

Кукуха отъезжает у истеричек, но она у них от всего подряд отъезжает.

Второй раз не читая ссылки тащишь. В XEmbed нужно дёрнуть XReparentWindow(), зная только WindowID дочерней проги. От самой проги тут ничего не требуется, WindowID тебе X-сервер скажет. То есть, она конечно может тебе его по dbus или ещё как прислать, но это совершенно не обязательно.

От самой проги тут ничего не требуется

Да господь:

A client that receives this messages knows that its window was embedded by an XEmbed site and not simply reparented by a window manager. To support toolkits that do not keep track of reparenting events, the message carries the embedder’s window handle as data1

Sent from the embedder to the client when the window becomes active or inactive, i.e. when the window gets or looses the keyboard input focus. If the client contains embedders itself, those have to pass the message through to their clients.

Sent from the client to the embedder when the client wants focus. The most common occasion is when the user clicks into one of the client’s child widgets, for example a line editor, in order to type something in.

Ну хватит уже отрицать реальность. Что то протокол и поддержки требует, что другое. Что одно в тулкиты засунуть можно, что другое.

Речь о страданиях авторов mpv, которые все волосы на жопе повыдирали пытаясь показать вам кино на вяленде.

Так вот этот пост и есть пост автора mpv, оло. Говорит хорошо стало:

Upstream Wayland basically fixed most of the technical things I complained about.

Ну хватит уже отрицать реальность.

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

Что то протокол и поддержки требует, что другое.

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

Что одно в тулкиты засунуть можно, что другое.

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

For example when a sandboxed client without file system access needs the user to select a file on the file system, given sandbox environment support, it can export its surface, passing the exported surface handle to an unsandboxed process that can show a file browser dialog and stack it above the sandboxed client’s surface.

Это даже близко не XEmbed. Ну то есть вообще ни разу.

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

Ну толсто же:

Sent from the client to the embedder when the client wants focus. The most common occasion is when the user clicks into one of the client’s child widgets, for example a line editor, in order to type something in.

Чтобы в этом окне что-то делать окно должно уметь обрабатывать события.

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

Так и для трея xembed никто не должен был использовать, а вышло что вышло.

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

Да LMAO же:

A client that receives this messages knows that its window was embedded by an XEmbed site and not simply reparented by a window manager. To support toolkits that do not keep track of reparenting events, the message carries the embedder’s window handle as data1

Ну тут черным по белому написано что тулкит либо одно уметь должен, либо другое.

Так и для трея xembed никто не должен был использовать, а вышло что вышло.

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

A client that receives this messages knows that its window was embedded by an XEmbed site and not simply reparented by a window manager. To support toolkits that do not keep track of reparenting events, the message carries the embedder’s window handle as data1

Ну тут черным по белому написано что тулкит либо одно уметь должен, либо другое.

Где написано? Ещё раз, ты можешь сделать XReparentWindow() на вообще любое окно. От окна ничего не требуется делать. Про то, что тулкит именно должен что-то уметь, тут не написано ничего.

Ещё раз, ты можешь сделать XReparentWindow() на вообще любое окно. От окна ничего не требуется делать. Про то, что тулкит именно должен что-то уметь, тут не написано ничего.

LMAO

LMAO

Ну с этим аргументом-то точно не поспоришь. Здаюзь, ты подебил!

Разработчики обычно любят ...

Знаешь что любят пользователи? Когда программы работают.

Программы пишут что бы пользователи ими пользовались.

Но только не для вялого, где показать кино это уже достижение

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

Это не ответ на вопрос.

Я бы задавал другой вопрос. Сравнялся ли Wayland с Xorg? Ответ на ближайшее десятилетие понятен, но так хотя бы ответить проще, а то для кого то терминал это уже десктоп.

Кстати, пробовал недавно waypipe, не завелось, какие то ошибки выдает. Я считаю Wayland опаздывает пока что на 41 год.

О! Это почти как моё любимое из GNOME Music:

https://gitlab.gnome.org/GNOME/gnome-music/-/issues/343

По ссылке чувак просит добавить регулировку громкости в этот плеер. Первый же ответ от разрабов:

This issue was already discussed a few years ago and closed as not a bug.

Why do you think a volume control is necessary?

Потом, правда, добавили. Спустя несколько лет. GNOME – это особое состояние души.

А когда сделают возможность нормального конфигурирования и отключения PRIMARY BUFFER, вместо этого стыда

А как в Wayland сделать включение PRIMARY BUFFER?

А как в Wayland сделать включение PRIMARY BUFFER?

Так оно включено.

К слову, я целиком и полностью согласен, что Xorg сосёт.

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

А в Weston копируется выделенный текст в буфер, да? Я помню были какие то проблемы.

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

У него код на Python:

https://gitlab.gnome.org/GNOME/gnome-music/-/blob/master/gnomemusic/asyncioli...

GNOME и другие приложения часто на JavaScript написаны.

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

Есть: разработчики не хотят направляться. Другая проблема в том, что некоторые решения потребуют сломать протокол. По мелочи, но всё таки. А это потребует изменений в клиентах. Если лет 15 назад это ещё можно было провернуть, то сегодня почти везде всунули поддержку Wayland и тебя с таким пошлют.

Плюс, там залежи говнокода после 30 лет разработки и трогать это многим страшно.

Есть: разработчики не хотят направляться

Это уже проблема в RH а не в разработчиках которые хотят справедливо получить зарплату.

Причем тут RH и деньги? А без вложений в Wayland, никто бы пилить его не начал. Я так считаю.

Плюс, там залежи говнокода после 30 лет разработки и трогать это многим страшно.

А конкретнее? Есть ссылки на файлы?

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

Расширить*? Уже много раз расширяли.

Оппа, а чё так? сишка же «язык богов», но утверждение всё равно верное, я так помню что гном поверх gtk сделан со всеми вытекающими, и всегда был убог на фоне плюсового KDE, сколько тот-же Gimp вымучивали…

Это уже проблема в RH а не в разработчиках которые хотят справедливо получить зарплату.

RH – не единственная контора, пилящая софт под лялекс. Желающих выделить с десяток разрабов на два года на перепил Xorg не нашлось пока что. Насколько я видел, если примерно человека три-четыре, пилящих основную ветку Xorg, и ещё несколько ребят из NetBSD поддерживают их форк, перекидываясь кодом с первыми. В NetBSD в частности из-за этого можно запустить современный софт на ооооооочччеееень древнем железе, поддержка которого из апстрима давно выкинута.

А конкретнее? Есть ссылки на файлы?

А любые открой. Там много странного.

Расширить*? Уже много раз расширяли.

Нет, именно поломать.

Нейт Грэм (Nate Graham), разработчик, занимающийся контролем качества в проекте KDE, опубликовал очередной отчёт о разработке KDE. После релиза KDE Plasma 6.3.0 выявлено несколько неприятных ошибок, которые планируют устранить в корректирующем обновлении 6.3.1, намеченном на 18 февраля. В сеансе на базе X11 выявлена проблема, приводящая к аварийному завершению композитного менеджера KWin при подключении нового экрана или переключении между экранами, подключёнными через HDMI. Пользователям KDE рекомендовано попробовать перейти на использование сеанса на базе протокола Wayland, так как разработчики KDE практически прекратили тестирование сеанса на базе X11.

Я думаю, тебе будет интересно узнать. Я только что воткнул внешний монитор по USB4 в ноут со свежим KWin 6.3.0 и… KWin сдох, утянув за собой весь графический сеанс и показав мне аж два чёрных экрана по цене одного. Восстановить никак не вышло, пришлось делать насильный ребут. Нюанс в том, что это было в режиме Wayland. Вот такое вот у нас тут тестирование, ребятушки.

И если под иксами KWin дохнет только сам, то тут полный фарш вместо системы. Даже в консоль по ctrl-alt-f1 не переключиться.

UPD: под иксами KWin кстати не дохнет. Только под Wayland. Вот и верь теперь в твои копипасты :(

UPD #2: взял флешку со свежей федорой. GNOME+Wayland тоже вешает ляптоп вусмерть.

А конкретнее? Есть ссылки на файлы?

А любые открой. Там много странного.

Да не заметил чего то плохого, в отличие от популярных zlib или libjpeg. Там чувствуется старина, а в Xorg приятный код, даже и не понять что код старый.

Вот и верь теперь в твои копипасты :(

Ну не верь.

Делать программы на С++ как MFC программисты из 90х это ничем не лучше.

А weston кто-то вообще пользуется?

Это же эталонная реализация, им могут и не пользоваться. Так вот, нормально работает там MOUSE3? Скопированный текст помещается в буфер?