Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

QtWayland 6.6 Brings Robustness Through Compositor Handoffs

blog.davidedmundson.co.uk

Post reply on HN
Print view View original

51–60 of 62 posts

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#51

Post by dekhn »

pseudotrash wrote: post #33
CoastalCoder wrote: post #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 oth…

Nitpick: there is no "vs." ... because in the long run X11 is dead. After decades of serving us well it's not maintainable and not a good base to build anything on top that you want to continue maintaining in 5 or 7 years. Any warranty of a "cyber physical systems" is better off starting on Wayland IMHO What issues are you facing with screen recording? Can't say anything about NVIDIA because I avoid these chipsets li…

X11 will continue to exist and be maintained for decades. I would not even be surprised if it lasts longer than Wayland.

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#52

Post by yjftsjthsd-h »

tadfisher wrote: post #50
yjftsjthsd-h wrote: post #24

Earlier quoted context omitted.

> That’s false in itself, what do you think Wayland protocols are? They might add some DE-specific protocol for themselves, but I don’t see why that would be a problem. It sure looks like it's true, or did GNOME/KDE/wlroots manage to agree on a single screenshot API?

Yeah, XDG portals. Not something that's essential to the display protocol. The idea that we need to be shoving tray icons and screen recording and permissions APIs into the display protocol is an Xism that folks need to let go. The display protocol should only deal with displaying things, meaning it's a standard way to give memory buffers to clients for them to draw into, and all the other crap can and should be hand…

Yeah, I'm a fan of it being an optional standard that's separate from the core display protocol. The problem is that it needs to be a standard, not 3 different standards because it wasn't standardized so 3 different groups created their own things, and all of the standards needed to replace X11 as it was actually used should have had a 1.0 spec before the whole mess was shipped to end users, let alone before users were told that this was the future that they needed to get on already.

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#53

Post by sprash »

akvadrako wrote: post #43
sprash wrote: post #34

Earlier quoted context omitted.

Rather the opposite. Wayland is a far more opaque abstraction layer than X11. Also the "robustness" is achieved with KDE/Qt specific protocols and as such has nothing to do with Wayland. Similar functionality could be achieved with X11.

X11 can't do this because memory allocations happen in the X server.

DRI3 clients allocate themselves their render buffers. Hence perfectly possible with X11.

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#54

Post by bombela »

tristan957 wrote: post #13
traverseda wrote: post #8

Earlier quoted context omitted.

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…

> unpaid volunteers This is not entirely true. A few GNOME developers within GTK/Mutter/GNOME Shell are paid to work on this kind of work at least part-time. SourceHut also pays Simon Ser to do some Wayland work, whether that is maintaining wayland-protocols or something else. > With the introduction of wayland they seem to be more set on forcing developers to choose, like they really are blocking tray icons now. Thi…

And Gnome is slow, with a completely limited UI that barely gives you anything of utility. The file selector is so bad (try selecting a file with the keyboard) and slow it's not even funny, it even has concurrency issues if you select things too fast!?, in Gnome applications, buttons keep changing places for no reasons, 30y olds shorcuts stop working an update to the next (like, press enter to validate), they refuse fractional scaling for... I don't know actually, etc, etx. I am sorry for the well intentioned people working on Gnome. But it's just a dumpster fire at this point.

And the tone in the Gnome issue tracker is insufferable. Everybody that suggest something or tries to help is a moron from their point of view.

I cannot help but think the people working on Gnome live in a weird bubble.

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#55

Post by hollerith »

bombela wrote: post #54
tristan957 wrote: post #13

Earlier quoted context omitted.

> unpaid volunteers This is not entirely true. A few GNOME developers within GTK/Mutter/GNOME Shell are paid to work on this kind of work at least part-time. SourceHut also pays Simon Ser to do some Wayland work, whether that is maintaining wayland-protocols or something else. > With the introduction of wayland they seem to be more set on forcing developers to choose, like they really are blocking tray icons now. Thi…

And Gnome is slow, with a completely limited UI that barely gives you anything of utility. The file selector is so bad (try selecting a file with the keyboard) and slow it's not even funny, it even has concurrency issues if you select things too fast!?, in Gnome applications, buttons keep changing places for no reasons, 30y olds shorcuts stop working an update to the next (like, press enter to validate), they refuse…

>they refuse fractional scaling

Huh? I'm using Gnome instead of MacOS because I can choose the size of the text and the other UI elements. On MacOS, the only choices that aren't blurry are 100% scaling and 200% scaling, but Gnome lets me set the scaling to an arbitrary value without blurriness. (I had to fuss with Emacs and my web browser to get them to be non-blurry when the scale factor is something other than 100%.)

Are there stupid design decisions in Gnome? Yes, but I've found Gnome to be usable with a little research (i.e., on how to set keyboard shortcuts for switching between apps instead of the "activities view").

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#56

Post by bombela »

hollerith wrote: post #55
bombela wrote: post #54

Earlier quoted context omitted.

And Gnome is slow, with a completely limited UI that barely gives you anything of utility. The file selector is so bad (try selecting a file with the keyboard) and slow it's not even funny, it even has concurrency issues if you select things too fast!?, in Gnome applications, buttons keep changing places for no reasons, 30y olds shorcuts stop working an update to the next (like, press enter to validate), they refuse…

>they refuse fractional scaling Huh? I'm using Gnome instead of MacOS because I can choose the size of the text and the other UI elements. On MacOS, the only choices that aren't blurry are 100% scaling and 200% scaling, but Gnome lets me set the scaling to an arbitrary value without blurriness. (I had to fuss with Emacs and my web browser to get them to be non-blurry when the scale factor is something other than 100%…

Ok now I am not sure which is which, what it working and what isn't anymore: https://wiki.archlinux.org/title/HiDPI#Fractional_scaling

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#57

Post by dale_glass »

dekhn wrote: post #51
pseudotrash wrote: post #33

Earlier quoted context omitted.

Nitpick: there is no "vs." ... because in the long run X11 is dead. After decades of serving us well it's not maintainable and not a good base to build anything on top that you want to continue maintaining in 5 or 7 years. Any warranty of a "cyber physical systems" is better off starting on Wayland IMHO What issues are you facing with screen recording? Can't say anything about NVIDIA because I avoid these chipsets li…

X11 will continue to exist and be maintained for decades. I would not even be surprised if it lasts longer than Wayland.

It already appears to be effectively dead. Pretty much all the commits in the repo are wayland related.

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#58

Post by JohnFen »

sho_hn wrote: post #17
p4bl0 wrote: post #6

Earlier quoted context omitted.

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 ju…

This is more or less what we once dreamed of doing with Activities in KDE 4, but couldn't make it work on X11 - we were banking on the X11 session handling protocols to implement the suspend/restore, only to find that few if any toolkits and apps implemented them properly, and that fixing this wasn't going to be viable due to a lot of spaghetti all over the place. This is partly why Activities ended up feeling somewh…

Interesting. I played with Activities for a while when they were introduced, but I've never understood what value they provide. I still don't, to be honest. But perhaps it's because they weren't able to provide value?

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#59

Post by sprash »

sho_hn wrote: post #31
sprash wrote: post #28

Earlier quoted context omitted.

> Wayland has some widely-respected values around who gets to introspect what state and who acts as authority And this is a main problem. These "widely-respected values" (by whom actually?) make sure that you can't implement an app that allows dragging tabs from one window to another because windows are not allowed to know their absolute coordinates. > But there's a lot of value in agreed-upon protocols, and X11 also…

> These "widely-respected values" (by whom actually?) make sure that you can't implement an app that allows dragging tabs from one window to another because windows are not allowed to know their absolute coordinates. I don't understand why they would need to for a DND operation (or why a custom protocol would be needed - X11 didn't need one for the same use case either). > Wayland as such has zero value. I still can'…

> I'm glad you care about the FOSS ecosystem this deeply. I do as well

As member of KDE e.V. board of directors you were part of the cancel brigade against Richard Stallman which was clearly an OP against FOSS. This means you are either some useful idiot or an actively malicious actor. Either way it would be great if people like you would stop "caring" about the FOSS ecosystem.

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#60

Post by FloatArtifact »

sho_hn wrote: post #18
CoastalCoder wrote: post #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 oth…

> (1) poor Wayland support in nVidia's proprietary drivers This has improved quite a bit with nVidia eventually implementing GBM support (so compositors no longer need an nVidia-specific codepath, which is nice). I use Plasma on Wayland on my nVidia-powered ThinkPad, and it's generally fine and has been for some time. That said, the nVidia stack does still feel a bit more hit and miss than some others. > (2) Wayland'…

Accessibility software needs access to the window details like executable, new title, window size and so forth and to be able to emulate peripherals.
Post reply on HN