#Linux #Ricing #AwesomeWM
Мой любимый оконник теперь на wayland?
Nani? Снова?

(somewm)
GitHub - trip-zip/somewm: Not quite awesome...just some.

Not quite awesome...just some. Contribute to trip-zip/somewm development by creating an account on GitHub.

GitHub
@skullgamer205 Так и что плохого, в постепенном отказе от X11/X.Org в пользу написания решения содержащих в себе Wayland compositor'ы (на базе каких-нибудь шаренных wlroots)?

#X11 устарел потому, что износился от обилия правок. А реализующий это всё #XOrg превратился в безальтернативного монополиста и перестав нормально развиваться.

Тут даже нет ситуации, вроде той, когда
#sytemd приходило на замену #initrc. Потому что #Wayland идёт не как замена Xorg'у, а является заменой X11-протокола, сам же по себе единственный в системе X-Server заменяется на множество Wayland compositors — каждый в своём оконном менеджере или среде.
@grumb, так я вроде не говорил про wayland плохого в данном посте. Я имел в виду, что это ещё одна попытка реализации AwesomeWM под wayland'ом... Но да ладно.
- - - -
Плохое может скорее в том, что он (wayland) менее поворотлив, чем Xorg. Если на иксах есть отдельно оконный менеджер и есть отдельно композитор (picom, xcompmgr), то в wayland это всё идёт скопом, и причём не каждый композитный менеджер имеет определённые возможности (к примеру некоторые фишки picom'а) и не каждый разработчик захочет их реализовывать, ссылаясь то на минимализм, то на нежелание делать впринципе, то на неправильную фазу луны.

Однако вяленый всё же работает лучше, функций где-то да больше или реализованы лучше, чем в иксах.

Иксы устарели - это факт. Однако иксы вполне себе неплохо работают и списывать их со счетов, заменяя (можно сказать, принудительно) их на вяленого, пока не стоит. В Wayland, как я замечал, плохо работают многооконные приложения (они работают, но соединять дочерние окна в одно; двигать дочерние окна - боль). Как пример: NanoCad, который под линь. В Artix'е под wayland'ом с двумя мониторами у него дочерние окна, когда пытаешься их двигать, перемещаются быстрее и дальше, чем мышь. Или опять же в том же нанокаде проблемно вернуть кусок панельки, которая стала дочерним окном, обратно.

То, что Xorg стал монополистом который перестал развиваться - есть такое. Но как слышал от различных шизов, его "замедлял" RedHat, поэтому я и считаю это слухом...

Ну насчёт SystemДы туь в целом интересно. Он идет не только как замена init'ам, а как целый швейцарский нож-комбайн из различных утилит и свистоперделок, которые, как опытные и не очень юзвери считают, к чертям не нужны. Но это ладно.
@skullgamer205 так Wayland это протокол и не более.

Описываемые тобой наблюдения не имеют отношения к протоколу и не могут быть обусловлены протоколом.
В той же Plasma KDE ни коим образом не наблюдается тех вещей про манипуляции с окнами. Потому что везде у каждой среды (Desktop Enviroment'а) или оконного менеджера должен быть свой вариант реализации Wayland-протокола, как бы свой X-server, но просто именуемый wayland-композитором.

Мы вступаем в такую эру, где каждый оконный менеджер (WM) пытающийся собой подменять графическую среду окружения (DE) будет вынужден использовать собственную реализацию Wayland-протокола, строясь вокруг своего собственного «композитора» (по факту являющегося x-server'ом).

@grumb

Описываемые тобой наблюдения не имеют отношения к протоколу и не могут быть обусловлены протоколом.Верно, они относятся к композитным менеджерам.В той же Plasma KDE ни коим образом не наблюдается тех вещей про манипуляции с окнами.Ну вот плазму в вяленом я не трогал, извиняюсь.

@skullgamer205 Нет такой вещи как wayland-сервер в системе на замену XOrg.
Вместо этого в одной системе сразу есть множество разных реализаций wayland-сервера (display server'а) в каждом из композитных оконных менеджеров.

Насколько хорошо разработчики конкретного оконного менеджера проработали wayland-сервер, настолько криво всё и будет в плане работы GUI.
Просто композитные оконные менеджеры (WM) были и до появления Wayland, а сами по себе реализации wayland-серверов принято именовать «Wayland compositor», чтобы не путать с классическим x-server на базе X11-протокола.

Есть несколько зрелых вариантов, у
KDE, GNOME, Sway

То в каких оборотах ты про это всё пишешь навивает мысли, что совершено заблудился и не ориентируешься. Не знаю, как ещё доходчивее это обрисовать.
Раньше в системе был display manager в лице x-server'а, потому что реализовывал X11-протокол. Теперь каждый маломальски продвинутый window manager несёт в составе себя свой собственный display manager реализующий Wayland-протокол.
Это примерно так же, как если бы WM & DE использовали в прошлом каждый свой вариант-форк XOrg'а или разные конкурирующие меж собой реализации X11 — т.е. внутри каждого был бы свой X-Server.
Wayland (protocol) - Wikipedia

@grumb

Просто композитные оконные менеджеры (WM) были и до появления Wayland ...Это ты про Compiz и Enlightment, как я понял (ну и про Kwin и Mutter)совершено заблудился и не ориентируешься.Немного есть такое. Скорее я больше привык к старому display manager'у.

@skullgamer205 Всё течёт, всё меняется.
Нельзя вечно толкаться вокруг display manager'ов на базе X11-протокола. Новые времена требуют большего, чем может предоставить тот
подход, который был с использованием X11.
Т.е. дело не в убогости самого по себе «X11 + расширения», а в том подходе, который используется в этом подходе к работе с клиентами (отрисовке окон и системе безопасности).

Этот самый
подход выражается в архитектуре — порядке взаимодействия и взаимосвязи элементов. Вот тут есть попытка изложить разницу подходов на сильно упрощённом отображении архитектуры (с высоты птичьего полёта).
Заодно становится ясно почему display manager'ы на базе Wayland-протокола называются «Wayland compositor» — вариантов особо других как-то и нету.
Wayland