undefined | Better HN

0 pointsSpivak5y ago0 comments

It's not that they're user-hateful it's just that they're (I think rightfully) being aggressive about scoping Wayland to things related to drawing surfaces and handling input events. If people started treating as one domain specific protocol that display servers use for drawing stuff on the screen and not "everything a desktop app might want to do" protocol there would be less conflict.

I'm glad they're leaving all the "desktop" stuff out and letting desktops agree on dbus interfaces. I doubt people writing little CLI utilities want to have to create dummy Wayland surfaces to do interact with the display server which is how wl-clipboard works.

0 comments

3 comments · 2 top-level

nerdponx5y ago· 1 in thread

So what does a Wayland-only future look like? Your clipboard, keyboard hotkey daemon, app runner, etc. all communicating happily over D-bus?

majewsky5y ago

Clipboard is handled by Wayland. Global hotkeys also needs to be handled by the Wayland compositor in some way since only the compositor has access to the full stream of input events. The compositor might choose to offload input events for known global hotkeys to some helper application, like kglobalacceld on Plasma.

CountSessine5y ago

Exactly. What we’re really seeing here is technical debt from the fact that we have so many different desktop environments. Much of the cost of having Gnome and KDE was hidden by the fact that a lot of the job of putting pixels on the screen and handling keyboard and mouse events was done (very badly) by X in one way or another.

Now the compositor/screen manager isn’t doing that anymore because it never should have and it was a terrible division or responsibility in the first place. But we have devs pushing forward on multiple different fronts with different DEs and development is painfully slow.

j / k navigate · click thread line to collapse