QtWayland 6.6 Brings Robustness Through Compositor Handoffs
blog.davidedmundson.co.uk
QtWayland 6.6 Brings Robustness Through Compositor Handoffs
1–10 of 62 posts
Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs
#2Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs
#3(This is genuinely interesting, I'm not sure how practical it is, but still very cool.)
Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs
#4As 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
#5The 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
#6Could 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.
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
#7Wasn't that just an issue with the Xlib interface? I thought Xcb made everything async.
Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs
#8Could 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…
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
#9Re: 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?
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.