Live data from Hacker News

QtWayland 6.6 Brings Robustness Through Compositor Handoffs

blog.davidedmundson.co.uk

1–10 of 62 posts

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#4
Could someone explain the significance of this for Wayland adoption?

As an outsider to the X11 vs. Wayland discussions, my impression has been that the main barriers to simply ditching X11 have been:

(1) poor Wayland support in nVidia's proprietary drivers

(2) Wayland's security model making some X11 use cases, e.g. screen recording, difficult or impossible.

Does QtWayland 6.6 address either of those (and/or some other) barriers?

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#5
[..] Compositors and displays servers are now the same process, doubling the space for errors

The wayland security model means the compositor absorbs even more functions from global shortcuts to screencasting and input-method handling [..]

Doesnt that mean, Wayland becomes everything that X11 was, just worse? I thought, Wayland was created to break up the monolithic X-Server?

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#6
post #2

Could this potentially open up the possibility of implementing a user-level desktop session serialization and restoration feature? Similar to how Emacs handles per-directory sessions.

It seems to be what they're going for at KDE:

https://floss.social/@kde/111051338968313784

> Plasma developer David Edmundson demonstrates how a desktop using Wayland, Qt6 and KWin can recover from a catastrophic crash as if nothing had happened.

> You will lose no data, the video you were watching will not skip a frame, and the contents of your clipboard will remain intact.

> The same principles can be applied to jumping from one desktop environment to another, for example, from Plasma to Gnome...

> ... And can provide a way to save _the state_ of an application to disk, stopping the app in its tracks and removing it from memory, so that later you can restore it just where you left off.

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#8

Could someone explain the significance of this for Wayland adoption? As an outsider to the X11 vs. Wayland discussions, my impression has been that the main barriers to simply ditching X11 have been: (1) poor Wayland support in nVidia's proprietary drivers (2) Wayland's security model making some X11 use cases, e.g. screen recording, difficult or impossible. Does QtWayland 6.6 address either of those (and/or some oth…

Well KDE has been pretty good about implementing wayland extensions for things like screen recording, accessibility, etc. Gnome has also been implementing extensions but they tend to go off and do their own thing.

The main barrier is honestly expecting a bunch of unpaid open source developers to go and re-implement everything. Stuff like barrier/synergy technically has the extensions needed to add in wayland support but it's still all unpaid volunteers.

There also used to be some more leeway about protocols and extensions. For a long time now Gnome has been saying "you're either a gnome app or you're not" when they deprecated stuff like tray icons. But there was generally a way back, a way to run your non-gnome app cleanly on Gnome. With the introduction of wayland they seem to be more set on forcing developers to choose, like they really are blocking tray icons now. There are common desktop extensions that Gnome just isn't really interested in developing.

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#10

[..] Compositors and displays servers are now the same process, doubling the space for errors The wayland security model means the compositor absorbs even more functions from global shortcuts to screencasting and input-method handling [..] Doesnt that mean, Wayland becomes everything that X11 was, just worse? I thought, Wayland was created to break up the monolithic X-Server?

The severely limited scope of Wayland forces all DE vendors to reinvent the wheel and basically recreate their own X11. But this time it's worse because the APIs are DE/Toolkit specific without the standardization that X11 offered.

Also X11 was never "monolithic" but in reality completely modular. It allows for example to change the window manager or even compositor at runtime without affecting running programs. For this to work your API hast to provide more functionality than your typical Wayland compositor. This is often mistaken for "monolithic" when in fact is actually the complete opposite of monolithic.

Post reply on HN