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.
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.
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.
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.
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.