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.
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).
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.
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.
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.
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.
They are called compositors, but they are not as good as X WMs IMO. I’m keeping an eye on them tho.
It still bothers me how toxic the hyprland devs behaved last year. Keeping an eye on that too 😉
Interesting. I’m curious about what seems to be missing in your use case?
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.
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).
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.
…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
To clarify: This causes problems like ugly font rendering and some games not working, etc.
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.
Java’s UI libraries are notorious for shoddy window handling, it also was a nightmare on X.
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.
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.