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

21–30 of 62 posts

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#21

Post by traverseda »

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…

I didn't mean unpaid Gnome developers, I meant everyone else. People like this SDL developer: https://gitlab.gnome.org/GNOME/mutter/-/issues/217#note_3552...

He's certainly not getting paid to make SDL work on Gnome, and I think does a pretty good job of explaining why the proposed solutions from Gnome will result in a poor user experience.

>This is also not true. GNOME has designs for tray icons in their GitLab repo.

Yeah, but every other wayland compositor seems to have gotten it to work already. This is what people mean when they talk about "splitting the linux ecosystem". If they're not able to manage the complexity of implementing stuff like tray icons, things that are really important for cross-platform apps, maybe they should pivot to using a library like wlroots.

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#22

Post by sho_hn »

traverseda wrote: post #21
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…

I didn't mean unpaid Gnome developers, I meant everyone else. People like this SDL developer: https://gitlab.gnome.org/GNOME/mutter/-/issues/217#note_3552... He's certainly not getting paid to make SDL work on Gnome, and I think does a pretty good job of explaining why the proposed solutions from Gnome will result in a poor user experience. >This is also not true. GNOME has designs for tray icons in their GitLab repo…

I don't know about the "on Gnome" part, specifically, but I think Ryan has done work on SDL on contract, or contributed to SDL as part of contract work on e.g. game ports. He's a prolific guy with many stories to tell about the Linux desktop, see https://icculus.org/~icculus/

I do get your point, though, and it's true, there's of course a lot of manhours on e.g. app fixes and porting, and many other things, that happen on a volunteer basis in the community to make it all work.

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#24

Post by yjftsjthsd-h »

kaba0 wrote: post #16
sprash wrote: post #10

Earlier quoted context omitted.

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…

> to reinvent the wheel Libraries are a thing > because the APIs are DE/Toolkit specific 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. > standardization that X11 offered What standardization? A single implementation that does its thing is not a standard, by definition. > Also X11 was never "monolit…

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

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#25

Post by traverseda »

sho_hn wrote: post #22
traverseda wrote: post #21

Earlier quoted context omitted.

I didn't mean unpaid Gnome developers, I meant everyone else. People like this SDL developer: https://gitlab.gnome.org/GNOME/mutter/-/issues/217#note_3552... He's certainly not getting paid to make SDL work on Gnome, and I think does a pretty good job of explaining why the proposed solutions from Gnome will result in a poor user experience. >This is also not true. GNOME has designs for tray icons in their GitLab repo…

I don't know about the "on Gnome" part, specifically, but I think Ryan has done work on SDL on contract, or contributed to SDL as part of contract work on e.g. game ports. He's a prolific guy with many stories to tell about the Linux desktop, see https://icculus.org/~icculus/ I do get your point, though, and it's true, there's of course a lot of manhours on e.g. app fixes and porting, and many other things, that happ…

Yeah, Icculus' case is a bit odd but also one of the strongest showing this in action. Barrier/synergy/input-leap (or whatever they're calling themselves these days) is another good example, but I can't just link to one polemic thread to get the point across. They've more or less just given up, despite the like 3 grand bug bounty for getting it working on wayland. Waypipe works, but ironically you can't forward x11 apps so you get into this weird situation where you need to use different protocols for different apps and you don't know which ahead of time.

OBS seems to finally be working with linux/wayland again, semi-reliably, and of course most things continue to work via x11 shims. It's getting closer, especially as Gnome gets closer to actually implementing a full set of desktop app protocols, but it is just a lot of work for toolkit developers to port everything over.

I still don't know how you'd go about running GUI apps inside docker containers, something we do at work for a few complicated deployments of ROS stuff (yes I'd rather do it some other way, but we don't have the man power).

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#27

Post by sprash »

kaba0 wrote: post #16
sprash wrote: post #10

Earlier quoted context omitted.

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…

> to reinvent the wheel Libraries are a thing > because the APIs are DE/Toolkit specific 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. > standardization that X11 offered What standardization? A single implementation that does its thing is not a standard, by definition. > Also X11 was never "monolit…

> They might add some DE-specific protocol for themselves, but I don’t see why that would be a problem.

What Wayland advocates don't see as a problem is the one of the main problems. I see a pattern here.

> years of hard work.

The only thing that takes "years of hard work" is writing a simple native Wayland client that takes screenshots.

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#28

Post by sprash »

sho_hn wrote: post #20
sprash wrote: post #10

Earlier quoted context omitted.

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…

> But this time it's worse because the APIs are DE/Toolkit specific without the standardization that X11 offered. On this one: It's not really that different. Very little if any KDE code made any direct calls to Xlib or xcb past the very early years. Most of this was also hidden by Qt abstractions, and toward app/shell devs most certainly by further KDE library abstractions. Directly interacting with X11 was an almos…

> 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 needed many of them.

Depends on the protocol. Wayland as such has zero value. I still can't decide that is designed by retarded morons ore geniuses as means of sabotage. Either way it destroys the FOSS ecosystem very effectively. Good job!

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#29

Post by tov_objorkin »

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…

One very stupid reason is the Qt itself, graphics application can't live without the QScreen instance. If user unplug every screen from the system, in order to prevent crash qt create the fake screen and hang in the headless state.

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#30

Post by agildehaus »

sprash wrote: post #10
PurpleRamen wrote: post #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?

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…

Wayland sounds a bit like what Vulkan is to OpenGL? Am I anywhere close?

I'm a novice when it comes to the implementation of compositors and display servers, but as a user it's been a far better experience than X11/Xorg ever was. Seeing this robustness video just proves it to me even more.

Post reply on HN