Wayland Clients Can Now Survive Qt Wayland Crashes / Compositor Restarts

[mdedetrich]

Is it possible to not start raging out in this forum? It's a freaking rage factory.

I know pretty well what a Wayland compositor and X11 window manager (plus X11 server) are. My point is, even if each Wayland compositor has to implement most of the features from the X11 server/wm/compositor combo again and again, that problem is still not technical, but a problem of fragmentation, because we could have easily one compositor or one library for compositors to rule it all, yet we don't have it (even the linked issue complained of having too few, lol), but that's related to organization and lack of a unified vision for the Linux desktop, and that's what we want, we want choice, but we can't complain we can't have both, resources are scarce.

Well its a problem thats the result of releasing a protocol in a vacuum without having any real implementation (there is a reference implementation called Weston but its really just for demo purposes). Normally when protocols get released its often in conjunction with an actual fully established implementation, think of HTTP. The only exception I can think of are protocols which are proven to be verified (i.e. Raft), but thats not Wayland so not relevant here.

Wayland devs should have worked with the major DE's to actually figure out what was needed before making an initial release of the protocol, and they should have released a much less biased version of wlroots along with the first release of the protocol to encourage code re-use. Instead we have the current situation

[Berniyh]

Yeah, considering that X11 window managers have nothing to do with Wayland compositors.

Wayland compositors are basically complete Xorg Server implementations. The complexity and the amount of features that need to be implemented are staggering.

Maybe start with the basics before heroically raging out about something you completely fail to understand.

Surely you got something to back that up? Can you list a couple of things that the compositors do on Wayland that they don't on X11?
What comes to my mind is drawing the final picture. Except … they kind of do that on X11 as well. They then just hand that image to X11 which hands it over to the graphics stack.

Yes, there are some new features needed, like VRR or HDR. But there, if you were to implement it on X11, you would have to introduce support on all compositors as well, wouldn't change that much.
Also keep in mind that when Wayland was designed, something like VRR or HDR wasn't really a thing in PCs.

[eagleoneraptor]

You're excellent at whataboutism: "Xorg is abandoned crap, thus the Wayland protocol is infallible". Kudos! The fact that 10 years after Wayland was released we have the only usable rich DE for it does not really raise any blaring alarms for the people who preach it day in and day out.

The fact that Qt has created clutches for the Wayland protocol, and so will have all the other Wayland toolkits later on, again doesn't ring any alarms.

The fact that a metric ton of features are reimplemented over and over is just fine.

You know what distinguishes successful OSes from the likes of Wayland? Rich freaking APIs. You don't code this crap for Windows, MacOS, etc. You're given APIs which survive a window manager restart right from the box. No one is even talking about it. No one even knows such an issue ... exists.

"In Wayland a single toolkit heroically resolves the core glaring issue, OMFG, that's so great!"

A neat graphical protocol. Woah. Over and out. This is disgusting and beyond stupid. Enjoy Gnome-Wayland.

Ha! And you were telling me I should calm down.

Again, do you know how to solve this? By a company that says: "Hey, I want to make money with a desktop OS, my engineering team told me I should invest my money on Qt and KDE, maybe have a design team to rewrite their crappy HIG. Also, use rpm-ostree and Flatpak for software management and invest a ton on Wine for compatibility. And don't forget of Wayland, don't use designs conceived in the 80s." and with the years, if the work is done right and the OS is commercialized properly, all other random toolkits will disappear, all other compositors reimplementing metric ton of features will disappear, all formats for distributing software will disappear, all the fragmentation will disappear.

Similar to what happened with Microsoft and VSCode that might be the most used editor in the world from day to night, making a lot of editors reimplementing a metric ton of features (text editing, syntax highlight, session management, whatever) disappear into oblivion.

Written from GNOME on Wayland

[Monsterovich]

… without mentioning that if said X11 server crashes, the applications are gone too.

In more than 10 years Xorg has never crashed for me. Even if something crashed, it never caused the whole server to crash. Xorg is pretty crash proof, so you don't need the crutches that you need in monolithic Wayland, where the compositor, window manager, and other things are all mixed together.

[MrCooper]

You're effing delusional if you think we're still in Wayland's "early days". Wayland's initial release was 30 Sept. 2008. It's now 2023 in case you've lost your calendar.

Were you using X around the millennium (when it was as old as Wayland is now)?

I was, it wasn't nearly as mature as Wayland is now.

[Weasel]

Surely you got something to back that up? Can you list a couple of things that the compositors do on Wayland that they don't on X11?
What comes to my mind is drawing the final picture. Except … they kind of do that on X11 as well. They then just hand that image to X11 which hands it over to the graphics stack.

It's more like they have to do more "outside the protocol spec" because that's how crippled and bullshit the Wayland protocol is.

And when you do stuff outside the spec, others will have their own solution.

Suddenly apps can't just use "Wayland" anymore, they have to use "Wayland KDE" or "Wayland GNOME" or whatever other crap with their custom APIs.

And you know who's fault this is? Wayland for having a crippledly useless protocol by design.

Wake me up when it can query absolute window positions of other processes (by same user and sandbox! i.e. the apps can read each other's memory already!!!), position windows on screen absolutely (at least, in the API, I don't care if some compositor refuses to follow suit, that's its problem then), grab pixels, etc.

Again, same user apps, same privilege, they can read each other's RAM. But suuuure, let's disallow them to do such basic things. Sane protocol.

[Berniyh]

It's more like they have to do more "outside the protocol spec" because that's how crippled and bullshit the Wayland protocol is.

Like what?

[RahulSundaram]

Well its a problem thats the result of releasing a protocol in a vacuum without having any real implementation (there is a reference implementation called Weston but its really just for demo purposes).

That isn't correct. Weston is a reference implementation and has been used in production devices for atleast a decade now. I would recommend watching this for the details and this blog post for a recent update. Collobora gets funding directly from commercial customers using it and wanting improvements on it. Not a demo.

[Weasel]

Like what?

I gave 3 examples in my post?

You can go further: screenshotting/grabbing the screen content, listening for keystrokes, hotkeys (which is a subset of that), inserting keys (macros), etc. Checking which Window is active, and its content.

Once again: applications under such same privilege can already read each other's memories, so if malware wanted to, it could already do this in a very hacky way. But malware doesn't care. So why are legit apps crippled?

You ask for actual real life apps that make use of them? Ok.

Automated software. Smart scripts that activate after specific keystrokes (think of auto-correct in phones) but only when specific app and specific window is active, etc. So you see, there are very many reasons for power users to have access to such information. Not malware.

Then you can automate apps that don't have such capability, read and even OCR the screen to take some data from their UI, insert clicks and keystrokes etc.

[mdedetrich]

That isn't correct. Weston is a reference implementation and has been used in production devices for atleast a decade now. I would recommend watching this for the details and this blog post for a recent update. Collobora gets funding directly from commercial customers using it and wanting improvements on it.

I did mention there was a reference implementation, how is that not correct?

Not a demo.

Unless its being used by existing major desktop environments (which I believe its not) than for all intents and purposes it practically is a demo. A reference implementation might prove that the protocol "works" in its own bubble, but it doesn't reflect the reality of the problems that the current desktop environments needs to solve.