I think this experiment really show how powerful the Wayland architecture can be. Wayland has faced a lot of criticism for its lack of network transparency, but as this video proves, the only real limitations are your skills and creativity.
But the problem is not and has never been that you can't write a Wayland compositor to do X or Y feature - if you're writing it you can make it do whatever you want. The problem is that any such feature is specific to one compositor - as an app developer I can never rely on such a feature existing because I will have users that will want to use my app under every compositor under the sun.
As an app developer, that doesn't matter, your app just needs to support the basic desktop protocols and this will automatically work without you having to do anything, that's the magic of Wayland.
well thats why we have standards bodies like wayland-protocols, its not perfect of course, but things work cross-compositor for the most part.
as an app developer I can never rely on such a feature existing
In that case you should gracefully degrade or if it is truly a necessary feature (e.g. you're trying to implement an IME and the compositor doesn't have input-method-unstable-v2) you should just display a popup to the user saying $DESKTOP does not support your app. The basics of window-handling/management in the protocol is perfectly fine for 99% of use cases as far as I'm concerned and any of the more complex requirements seem to me trivially degradable, e.g. relative window placement using ext-zones (so that an application can e.g. spawn a separate taskbar above the main window) could easily degrade into letting the compositor spawn the windows how it chooses if it doesn't support ext-zones .
Except people who need to implement compositors that either don't need nor want such protocols, or for which those protocols don't make much sense for where their compositor is running (e.g. VR compositors or compositors for TV screens). When an application absolutely needs a protocol and the compositor doesn't support the protocol it is often for a good reason, Gamescope is an example of such a compositor that intentionally doesn't offer many protocols to the applications it renders, there was also that recently posted Wayland in Minecraft mod where a protocol such as e.g. wlr-layer-shell, Server-Side decorations or pointer warp probably wouldn't make much sense (Gamescope also doesn't support wlr-layer-shell or SSD). The black sheep of course is Mutter (gnomes compositor), but even then the areas where they disagree is like... 5 protocols that are for the most part easily degradable? IDK, in my experience things work perfectly fine cross-compositor, and if a protocol is not supported the application just gracefully degrades.
Why hold Wayland compositors to a higher standard than X window managers? We tend to ignore how fragmented and inconsistent X11 actually was. ICCCM was a mess for years, but somehow we expect Wayland to be perfect. Don't forget that incentives drive development: compositor devs want users. If an app is crucial to the community, compositors will support it. In practice, this compatibility issue solves itself over time.
Large parts of X11 are still a mess - but they are just ignored by toolkits so things look fine. Long ago toolkit developers moved to different solutions than what X11 provides such as font handling.
Why hold Wayland compositors to a higher standard than X window managers? We tend to ignore how fragmented and inconsistent X11 actually was. ICCCM was a mess for years, but somehow we expect Wayland to be perfect. Don't forget that incentives drive development: compositor devs want users. If an app is crucial to the community, compositors will support it. In practice, this compatibility issue solves itself.
Why hold Wayland compositors to a higher standard than X window managers? X11 window managers were always fragmented and inconsistent (ICCCM anyone?), but no one complained about it then. Don't forget that incentives drive development: compositor devs want users. If an app is crucial to the community, compositors will support it. In practice, this compatibility issue solves itself.
Network transparency isn't even used much let alone a requirement. For anyone who needs such a tool they exist to plop on top of Wayland
The only reason people even being that up is it's some arbitrary thing they pretend matters so much but in reality forcing network transparency into a local desktop display server would break kiss which is ironic considering the same people demanding this claim Wayland breaks Kiss.
Absolutely, and I think the beauty of Wayland is in how it's just a protocol for passing buffers around. You can do pretty much anything with that approach. It's ironic indeed that the same people who like UNIX don't see the simplicity in it.
You mistake the intentions of the complainers. It isn't about the "Unix philosophy", or network transparency or SysV init. What they want is a frozen architecture, so they can just sit back and coast on their crystalized mental models of Linux. "I've learned it once, why should I have to learn it again?"
They tell themselves that the myth of choice means that they get to dictate where development has to go. Which seems to point to nowhere, because listening to these stick in the muds would yield distributions using SysV init, X.org display server, using mknod on a static /dev directory, using tarballs for a.out software installation and Fvwm95 for a window manager and running NCSA Mosaic to browse the web.
That makes sense. I know a guy who is exactly like that. He refuses to move to KDE 6 and is still using sysvinit with ext4. I've been telling him about Wayland, not trying to persuade him to switch but just attempting to educate him because he seems to believe every Red Hat conspiracy theory out there. He just won't listen. I think I'm done trying since he's more interested in BSD and XLibre anyway, so I'm not sure why I keep wasting my time.
Absolutely, and I think the video demonstrates how Wayland is just a protocol for passing buffers around. You can do pretty much anything with that approach. It's ironic indeed that the same people who like UNIX don't see the simplicity in it.
mortuary-dreams@reddit (OP)
I think this experiment really show how powerful the Wayland architecture can be. Wayland has faced a lot of criticism for its lack of network transparency, but as this video proves, the only real limitations are your skills and creativity.
jcelerier@reddit
But the problem is not and has never been that you can't write a Wayland compositor to do X or Y feature - if you're writing it you can make it do whatever you want. The problem is that any such feature is specific to one compositor - as an app developer I can never rely on such a feature existing because I will have users that will want to use my app under every compositor under the sun.
Yeox0960@reddit
As an app developer, that doesn't matter, your app just needs to support the basic desktop protocols and this will automatically work without you having to do anything, that's the magic of Wayland.
jcelerier@reddit
So how do I inject keypressesor listen to global keypresses in a way that works on every Wayland system ever
Yeox0960@reddit
That's the neat part, you don't.
tukanoid@reddit
Or use evdev (unless im missing smth obvious, havent had to deal with global keypress handling at work or for personal projects yet)
Misicks0349@reddit
well thats why we have standards bodies like wayland-protocols, its not perfect of course, but things work cross-compositor for the most part.
In that case you should gracefully degrade or if it is truly a necessary feature (e.g. you're trying to implement an IME and the compositor doesn't have
input-method-unstable-v2) you should just display a popup to the user saying $DESKTOP does not support your app. The basics of window-handling/management in the protocol is perfectly fine for 99% of use cases as far as I'm concerned and any of the more complex requirements seem to me trivially degradable, e.g. relative window placement using ext-zones (so that an application can e.g. spawn a separate taskbar above the main window) could easily degrade into letting the compositor spawn the windows how it chooses if it doesn't support ext-zones .jcelerier@reddit
It's exactly the part that is unacceptable
Misicks0349@reddit
Except people who need to implement compositors that either don't need nor want such protocols, or for which those protocols don't make much sense for where their compositor is running (e.g. VR compositors or compositors for TV screens). When an application absolutely needs a protocol and the compositor doesn't support the protocol it is often for a good reason, Gamescope is an example of such a compositor that intentionally doesn't offer many protocols to the applications it renders, there was also that recently posted Wayland in Minecraft mod where a protocol such as e.g.
wlr-layer-shell, Server-Side decorations or pointer warp probably wouldn't make much sense (Gamescope also doesn't support wlr-layer-shell or SSD). The black sheep of course is Mutter (gnomes compositor), but even then the areas where they disagree is like... 5 protocols that are for the most part easily degradable? IDK, in my experience things work perfectly fine cross-compositor, and if a protocol is not supported the application just gracefully degrades.mortuary-dreams@reddit (OP)
Why hold Wayland compositors to a higher standard than X window managers? We tend to ignore how fragmented and inconsistent X11 actually was. ICCCM was a mess for years, but somehow we expect Wayland to be perfect. Don't forget that incentives drive development: compositor devs want users. If an app is crucial to the community, compositors will support it. In practice, this compatibility issue solves itself over time.
jcelerier@reddit
it does not. https://github.com/swaywm/wlroots/issues/2378
ilep@reddit
Large parts of X11 are still a mess - but they are just ignored by toolkits so things look fine. Long ago toolkit developers moved to different solutions than what X11 provides such as font handling.
mortuary-dreams@reddit (OP)
Why hold Wayland compositors to a higher standard than X window managers? We tend to ignore how fragmented and inconsistent X11 actually was. ICCCM was a mess for years, but somehow we expect Wayland to be perfect. Don't forget that incentives drive development: compositor devs want users. If an app is crucial to the community, compositors will support it. In practice, this compatibility issue solves itself.
mortuary-dreams@reddit (OP)
Why hold Wayland compositors to a higher standard than X window managers? X11 window managers were always fragmented and inconsistent (ICCCM anyone?), but no one complained about it then. Don't forget that incentives drive development: compositor devs want users. If an app is crucial to the community, compositors will support it. In practice, this compatibility issue solves itself.
the_abortionat0r@reddit
Network transparency isn't even used much let alone a requirement. For anyone who needs such a tool they exist to plop on top of Wayland
The only reason people even being that up is it's some arbitrary thing they pretend matters so much but in reality forcing network transparency into a local desktop display server would break kiss which is ironic considering the same people demanding this claim Wayland breaks Kiss.
mortuary-dreams@reddit (OP)
Absolutely, and I think the beauty of Wayland is in how it's just a protocol for passing buffers around. You can do pretty much anything with that approach. It's ironic indeed that the same people who like UNIX don't see the simplicity in it.
ronaldtrip@reddit
You mistake the intentions of the complainers. It isn't about the "Unix philosophy", or network transparency or SysV init. What they want is a frozen architecture, so they can just sit back and coast on their crystalized mental models of Linux. "I've learned it once, why should I have to learn it again?"
They tell themselves that the myth of choice means that they get to dictate where development has to go. Which seems to point to nowhere, because listening to these stick in the muds would yield distributions using SysV init, X.org display server, using mknod on a static /dev directory, using tarballs for a.out software installation and Fvwm95 for a window manager and running NCSA Mosaic to browse the web.
mortuary-dreams@reddit (OP)
That makes sense. I know a guy who is exactly like that. He refuses to move to KDE 6 and is still using sysvinit with ext4. I've been telling him about Wayland, not trying to persuade him to switch but just attempting to educate him because he seems to believe every Red Hat conspiracy theory out there. He just won't listen. I think I'm done trying since he's more interested in BSD and XLibre anyway, so I'm not sure why I keep wasting my time.
mortuary-dreams@reddit (OP)
Absolutely, and I think the video demonstrates how Wayland is just a protocol for passing buffers around. You can do pretty much anything with that approach. It's ironic indeed that the same people who like UNIX don't see the simplicity in it.
mortuary-dreams@reddit (OP)
Video: https://www.youtube.com/watch?v=tRx75piIlxo