Not OP, but modularity. An X11 WM is just a WM. You can choose compositor, bar, shortcut daemon, etc. With Wayland, a single implementation holds most of that, and more. If you need a specific feature from your display server, you are stuck on WMs that support it. This has forced me to use KDE for Wayland on my main workstation, and although it works well, it’s not my prefered WM/workflow.
Alongside that, no clones of several X11 WMs exist. bspwm for example. Riverwm exists, but has major limitations, and the workflow isn’t the same.
In practice wayland is way more composable that one would, at first glance, expect, and even accidentally so, because DEs are made up of different components often sharing common interfaces, so the cosmic task bar will run under the sway compositor and suchlike. Not just “run” as in “not crash” but “actually display tasks based on information from the compositor”. I expect further standardisation there once the ecosystem matures a bit more. Just because you can include a task bar directly in the compositor process doesn’t mean you have to, and the same goes for window rules, window decorators, whatnot.
The status bar example holds for xorg as well… What wm doesn’t ship its own bar nowadays? The only one I can think of is bspwm. But nothing stops you from disabling the native bar and using your own
Trying to replace KDE’s task bar is quite more involved than exchanging all those minimalist bars for tiling wms, it’s way more tightly integrated. It is a separate process even on wayland, though, so the API to e.g. get live video previews of windows is exposed, in principle anyone can use it as long as KDE spawns you as a task bar and thus grants you access to the API. Which is probably just a matter of changing an obscure config file somewhere, they never hardcode such things.
And if you’re comfortable with them changing the API under your feet because they probably didn’t submit it on the standards track because, as said, the whole ecosystem isn’t exactly mature, DEs themselves are still figuring out how to best do things and to establish a standard they actually have to agree on a common approach. There’s no taskbar stardard for X btw, either, or at least xmobar is being fed a proprietary format string via fifo every update. It’s basically just a fancy text box.
With a library like Wlroots you almost get that, it’s just in-process rather than out of process. The real problem there is doing some fancier things requires nonstandard Wayland extensions with low support across the ecosystem.
Depends things like shaped window borders for theming, title bars in hyprland, effects, pagers, some automation options, etc…
What I generally miss in Wayland is better mouse automation support, Java support, the ability to have multiple mouse cursors and assign them to different input devices.
So what you’re saying is, it’s not so much that Java support is missing from Wayland (which wouldn’t make sense to begin with), it’s that Wayland support is missing from Java.
This is technically correct, and you’re right about where the blame lies, but I suspect for most people holding off on switching, the difference is academic.
export _JAVA_AWT_WM_NONREPARENTING=1 is one of those magical make-everything-better incantations that really makes you wonder why the fuck it isn’t the default behavior
Depends things like shaped window borders for theming, title bars
All possible. X had some age-old protocol enabling oval and whatnot windows and noone ever used it, whether you use CSD or SSD you can paint with alpha and say “nope, that mouse click wasn’t for me”. So even if logically all windows are rectangular because that makes sense because textures are rectangular and you really don’t want to complicate things at that level, UX-wise you can have fractal borders if you really want.
in hyprland,
…anything “in hyperland” is a hyperland problem, not a wayland problem.
effects, pagers, some automation options, etc…
All Things compositors can do.
What I generally miss in Wayland is better mouse automation support,
Faking input devices is compositor responsibility, for obvious security reasons.
Java support,
As if Java and X work well together.
the ability to have multiple mouse cursors and assign them to different input devices.
Weston does this, protocols support it, I don’t think it’s much of a priority for other compositors. The most common multiple pointing device configuration is to have both devices control one pointer. My tablet works and the tip is properly analogue that’s plenty of functionality for me (dunno if tilt works by now, blender doesn’t use it anyways).
So this is my big issue with Wayland - nothing is a ”Wayland problem”. Everything lands on the compositors. Features that existed for the past few decades in X and are deeply integrated into the ecosystem were relegated to second class citizens or just ignored. (Can we share our screens with Zoom yet?)
I won’t argue that X is flawless or should live forever. X should die. However, X actually solved problems instead of just providing a bunch of (IMHO) half baked ”protocols” so that someone else can solve the problem. From the perspective of a user or application developer, that’s just hot potatoes being passed around. And there have been plenty of hot potatoes the past decade.
Thank you for reading my yearly Wayland rant. I’ll now disappear into my XMonad-fueled bliss, fully software rendered.
Everything lands on the compositors. Features that existed for the past few decades in X and are deeply integrated into the ecosystem were relegated to second class citizens or just ignored
There were ten years that the desktop environment people wasted, where all those interfaces could have been created but they only started in earnest once the x.org devs put their foot down and said “nope we’re serious x.org is unmaintainable we’re not doing this any more”.
And no, X didn’t solve any of those problems – what it did was provide completely unrestricted access to everything to anyone and it took multiple decades before different clients would stop fighting each other over control over the desktop. That clusterfuck was one of the things that x.org devs wanted to avoid, but they, not being DE devs, also didn’t know what DE people actually needed. So they asked. And, as said, didn’t get an answer.
I have no idea what real world threat model and threat actor the Wayland people are going for. A threat actor with code execution on a Linux desktop immediately has access to the filesystem and can do whatever anyway, in practice (see also: Steam deleting home directories). Privilege Escalation is a thing and namespaces in Linux are kinda meh. Run your untrusted code in an ephemeral VM.
My point is just that once you have a threat actor running code on your system, it’s game over regardless of whatever your desktop tries to do. (I’ll run with the Maginot Line comparison here, but Wayland is more like a locked door without walls.)
The security issues with X were the X-Forwarding-stuff being kinda bad, not the ”full access to everything”-stuff. I want my applications to access my things, otherwise I wouldn’t run the application.
If your threat model seriously needs sandboxing, you’ll wanna go the Qubes-route. Anyways, Arcan seems to have a more reasonable threat model than Wayland if you wanna go that route.
Thanks for reading my yearly mini rant on why Wayland’s security don’t matter and only gets in the way of the user and application developer.
There’s no X WMs that fake input devices, or organise global hotkeys, or a thousand other things people always quote when bashing wayland. You can get bog-standard X applications which do that because X has literally no security model, but the feature set between e.g. KDE on X and KDE on wayland is virtually identical.
It’s like you want to misunderstand me. I’m not bashing Wayland. That part of my comment isn’t about WMs and compositors. It’s about how hard it is to make macro that does a few clicks and types a few keys into an app etc… It’s still very hard in Wayland. I’m sure it will get better some day, but we’re not there yet.
Interesting. I’m curious about what seems to be missing in your use case?
Not OP, but modularity. An X11 WM is just a WM. You can choose compositor, bar, shortcut daemon, etc. With Wayland, a single implementation holds most of that, and more. If you need a specific feature from your display server, you are stuck on WMs that support it. This has forced me to use KDE for Wayland on my main workstation, and although it works well, it’s not my prefered WM/workflow.
Alongside that, no clones of several X11 WMs exist. bspwm for example. Riverwm exists, but has major limitations, and the workflow isn’t the same.
In practice wayland is way more composable that one would, at first glance, expect, and even accidentally so, because DEs are made up of different components often sharing common interfaces, so the cosmic task bar will run under the sway compositor and suchlike. Not just “run” as in “not crash” but “actually display tasks based on information from the compositor”. I expect further standardisation there once the ecosystem matures a bit more. Just because you can include a task bar directly in the compositor process doesn’t mean you have to, and the same goes for window rules, window decorators, whatnot.
The status bar example holds for xorg as well… What wm doesn’t ship its own bar nowadays? The only one I can think of is bspwm. But nothing stops you from disabling the native bar and using your own
xmonad doesn’t, though using xmobar is common.
Trying to replace KDE’s task bar is quite more involved than exchanging all those minimalist bars for tiling wms, it’s way more tightly integrated. It is a separate process even on wayland, though, so the API to e.g. get live video previews of windows is exposed, in principle anyone can use it as long as KDE spawns you as a task bar and thus grants you access to the API. Which is probably just a matter of changing an obscure config file somewhere, they never hardcode such things.
And if you’re comfortable with them changing the API under your feet because they probably didn’t submit it on the standards track because, as said, the whole ecosystem isn’t exactly mature, DEs themselves are still figuring out how to best do things and to establish a standard they actually have to agree on a common approach. There’s no taskbar stardard for X btw, either, or at least xmobar is being fed a proprietary format string via fifo every update. It’s basically just a fancy text box.
With a library like Wlroots you almost get that, it’s just in-process rather than out of process. The real problem there is doing some fancier things requires nonstandard Wayland extensions with low support across the ecosystem.
Depends things like shaped window borders for theming, title bars in hyprland, effects, pagers, some automation options, etc…
What I generally miss in Wayland is better mouse automation support, Java support, the ability to have multiple mouse cursors and assign them to different input devices.
…what?
Java GUI applicatiins have to use the X compatibility layer of Wayland at the moment, because Wayland support hasn’t been integrated into JREs yet
So what you’re saying is, it’s not so much that Java support is missing from Wayland (which wouldn’t make sense to begin with), it’s that Wayland support is missing from Java.
This is technically correct, and you’re right about where the blame lies, but I suspect for most people holding off on switching, the difference is academic.
If we’re talking about “most people… switching” then IMO the real biggest factor is when their distro will decide to use it by default.
To clarify: This causes problems like ugly font rendering and some games not working, etc.
Java’s UI libraries are notorious for shoddy window handling, it also was a nightmare on X.
export _JAVA_AWT_WM_NONREPARENTING=1is one of those magical make-everything-better incantations that really makes you wonder why the fuck it isn’t the default behaviorOh i see. I thought there was more to it – but I guess it’s just Java being horrible as usual.
All possible. X had some age-old protocol enabling oval and whatnot windows and noone ever used it, whether you use CSD or SSD you can paint with alpha and say “nope, that mouse click wasn’t for me”. So even if logically all windows are rectangular because that makes sense because textures are rectangular and you really don’t want to complicate things at that level, UX-wise you can have fractal borders if you really want.
…anything “in hyperland” is a hyperland problem, not a wayland problem.
All Things compositors can do.
Faking input devices is compositor responsibility, for obvious security reasons.
As if Java and X work well together.
Weston does this, protocols support it, I don’t think it’s much of a priority for other compositors. The most common multiple pointing device configuration is to have both devices control one pointer. My tablet works and the tip is properly analogue that’s plenty of functionality for me (dunno if tilt works by now, blender doesn’t use it anyways).
So this is my big issue with Wayland - nothing is a ”Wayland problem”. Everything lands on the compositors. Features that existed for the past few decades in X and are deeply integrated into the ecosystem were relegated to second class citizens or just ignored. (Can we share our screens with Zoom yet?)
I won’t argue that X is flawless or should live forever. X should die. However, X actually solved problems instead of just providing a bunch of (IMHO) half baked ”protocols” so that someone else can solve the problem. From the perspective of a user or application developer, that’s just hot potatoes being passed around. And there have been plenty of hot potatoes the past decade.
Thank you for reading my yearly Wayland rant. I’ll now disappear into my XMonad-fueled bliss, fully software rendered.
There were ten years that the desktop environment people wasted, where all those interfaces could have been created but they only started in earnest once the x.org devs put their foot down and said “nope we’re serious x.org is unmaintainable we’re not doing this any more”.
And no, X didn’t solve any of those problems – what it did was provide completely unrestricted access to everything to anyone and it took multiple decades before different clients would stop fighting each other over control over the desktop. That clusterfuck was one of the things that x.org devs wanted to avoid, but they, not being DE devs, also didn’t know what DE people actually needed. So they asked. And, as said, didn’t get an answer.
Sure, I’ll do another mini-rant.
I have no idea what real world threat model and threat actor the Wayland people are going for. A threat actor with code execution on a Linux desktop immediately has access to the filesystem and can do whatever anyway, in practice (see also: Steam deleting home directories). Privilege Escalation is a thing and namespaces in Linux are kinda meh. Run your untrusted code in an ephemeral VM.
My point is just that once you have a threat actor running code on your system, it’s game over regardless of whatever your desktop tries to do. (I’ll run with the Maginot Line comparison here, but Wayland is more like a locked door without walls.)
The security issues with X were the X-Forwarding-stuff being kinda bad, not the ”full access to everything”-stuff. I want my applications to access my things, otherwise I wouldn’t run the application.
If your threat model seriously needs sandboxing, you’ll wanna go the Qubes-route. Anyways, Arcan seems to have a more reasonable threat model than Wayland if you wanna go that route.
Thanks for reading my yearly mini rant on why Wayland’s security don’t matter and only gets in the way of the user and application developer.
No.
You misunderstood totally. I’m not saying it’s not possible. There isn’t a compositor making use of those things, but many X WMs that do.
There’s no X WMs that fake input devices, or organise global hotkeys, or a thousand other things people always quote when bashing wayland. You can get bog-standard X applications which do that because X has literally no security model, but the feature set between e.g. KDE on X and KDE on wayland is virtually identical.
It’s like you want to misunderstand me. I’m not bashing Wayland. That part of my comment isn’t about WMs and compositors. It’s about how hard it is to make macro that does a few clicks and types a few keys into an app etc… It’s still very hard in Wayland. I’m sure it will get better some day, but we’re not there yet.
Have a look here. Not sure how they do it the proper way would be to run the desktop environment as a subcompositor of autokey.
Meanwhile, though, do try CLI automation. It’s the Unix way.