SDL3 Begins Dumping A Lot Of Old Code: GLES1, OS/2, DirectFB, WinRT, NaCl & More

[ssokolow]

Here is the thing though... The thing you are asking for is like asking for driving around without a three-point safety belt in your car. Let's say Volvo disabled this feature, the car won't even start unless you have plugged in the safety belt. Would disabling this behavior make the car safer? Same thing about the security layers that are right now ruining your feature. The fact that it breaks your feature does not mean disabling the mechanisms make your system more secure.

No, I'm saying that I want the seatbelts and, because Wayland is the "uncomfortable 1960s/1970s seatbelts" of security, we're seeing a burgeoning market in DIY seatbelt de-installation kits, just like how, before seatbelts were mandatory in the U.S., you actually did see people who were handy with tools removing them when they came standard.

Crash recovery for graphics is tricky, require the cooperation of one of the most notoriously un-cooperative companies in the Linux space (you know who) and requires a holistic overview of the entire graphics stack to even begin to understand where to begin. If you think your feature is hard to implement, wait until you start with this

Didn't Enlightenment come up with something along the lines of "If the compositor crashes, the E-toolkit apps wait for the compositor's watchdog to restart it and then use a session restore-esque protocol to negotiate restoring the window state and geometry while restoring their own internal state themselves"? That sounds like a paradigm that Qt could handle if KWin implemented it without needing special help from the drivers. (And I suppose GTK too. I'm still shackled to them for Inkscape.)

Patches welcome, as always.

If there's one thing I know, it's that I'm not qualified to write reliable C or C++. I'm a QBasic→Visual Basic→Perl→Python/PHP/JavaScript/CoffeeScript → Rust/TypeScript developer and I came to Rust to do Python-y things with more compile-time correctness than MyPy can offer, not to do stuff that Python is incapable of.

[wertigon]

My issue isn't with Wayland-based desktops not supporting my use-cases. I know they will. My issue is that I actually want my desktop to be secure and these stubborn man-children are pushing the pragmatists to circumvent their system entirely.

Here is the thing though... The thing you are asking for is like asking for driving around without a three-point safety belt in your car. Let's say Volvo disabled this feature, the car won't even start unless you have plugged in the safety belt. Would disabling this behavior make the car safer? Same thing about the security layers that are right now ruining your feature. The fact that it breaks your feature does not mean disabling the mechanisms make your system more secure.

Hell, I've mentioned before that, if Wayland-based compositors don't agree on a crash recovery mechanism at least as robust as what I'm used to from X.org's current stability before X11 gets retired, I'll probably be setting up some kind of unholy abomination like "Run a kiosk-mode Wayland compositor for hardware support, then run Xpra on top of it for detach/re-attach support, then run kwin_wayland's X11 backend on top of that for an actual desktop".

...either that or just go the ChromeOS route and make everything a web app or MPD or some other client-server system where the UI dying doesn't take down the actual application, forcing every application to reinvent what even Windows XP figured out.

Crash recovery for graphics is tricky, require the cooperation of one of the most notoriously un-cooperative companies in the Linux space (you know who) and requires a holistic overview of the entire graphics stack to even begin to understand where to begin. If you think your feature is hard to implement, wait until you start with this

Patches welcome, as always.

[ssokolow]

Hard, not impossible. It can be solved by the community for the community by, for instance, creating an accessibility fork of Mutter that can then upstream accessibility fixes. This can then be included in Ubuntu, Debian and so on.

Or, as we're already seeing the community do, just doing an end-run around that oh-so-beautiful security model, as I mentioned.

My issue isn't with Wayland-based desktops not supporting my use-cases. I know they will. My issue is that I actually want my desktop to be secure and these stubborn man-children are pushing the pragmatists to circumvent their system entirely.

Hell, I've mentioned before that, if Wayland-based compositors don't agree on a crash recovery mechanism at least as robust as what I'm used to from X.org's current stability before X11 gets retired, I'll probably be setting up some kind of unholy abomination like "Run a kiosk-mode Wayland compositor for hardware support, then run Xpra on top of it for detach/re-attach support, then run kwin_wayland's X11 backend on top of that for an actual desktop".

...either that or just go the ChromeOS route and make everything a web app or MPD or some other client-server system where the UI dying doesn't take down the actual application, forcing every application to reinvent what even Windows XP figured out.

[wertigon]

making a swiss army knife for accessibility fails. you need the ability to pick and choose to make your environment suit you needs, something that wayland makes incredibly hard.

Hard, not impossible. It can be solved by the community for the community by, for instance, creating an accessibility fork of Mutter that can then upstream accessibility fixes. This can then be included in Ubuntu, Debian and so on.

Or we can sit around complaining uselessly about it in a cirkle-jerk until the train leaves the station, and you get left behind on an ancient technology that won't ever get updated. Which is the default position. Already saw it happen with Amiga and those folks grudgingly abandoned the platform one by one in the early noughties. This will be similar. The old tech won't necessarily disappear; just become more and more unsupported as time moves on.

[Quackdoc]

Is it not better to design a compositor focused 100% on accessibility, rather than trying to shoehorn accessibility needs into compositors not built for that purpose? These could then break out the features into small modules that, with a permissible license, could easily cross pollinate other compositors.

Absolutely not. Accessibility needs are so varied, you would have better luck trying to compete with a professional sniper in a sharp shooting competition using a shotgun. what accessibility needs is a cohesive and flexible ecosystem. even for people who need on screen keyboards, you need to have a choice between 4 different OSKs because one OSK will work for someone, but not someone else.

making a swiss army knife for accessibility fails. you need the ability to pick and choose to make your environment suit you needs, something that wayland makes incredibly hard.

[wertigon]

because needing to add this protocol to every compositor is a shit show, gnome as already stated they aren't interested in implementing non official protocols. and currently we for compositors we have off the top of my head

• kwin
• mutter
• wlroots
• smithay
• weston

which means you need to add that opt-in extension to at least the top 4 being what most compositors are going to be made from. this means you need to get all of these guys to agree on a single protocol, which has proved impossible. just ask for idle inhibit or wlr layers on gnome, go on, do it. then realize how stupid you sound Because as said before, people already tried.

and no, "just don't support X compositor that doesn't have support for Y protocol" is not a good solution.

You do realize that while this will not cover every possible use case and lead to gaps, it is still the best that can be done given other security restraints?

Would you argue for Amiga style memory handling too if that would help implement an accessibility feature? Do we compromise or not?

Is it not better to design a compositor focused 100% on accessibility, rather than trying to shoehorn accessibility needs into compositors not built for that purpose? These could then break out the features into small modules that, with a permissible license, could easily cross pollinate other compositors.

After that it is up to every compositor to make their own. Do try to make these easy to integrate into GTK and QT tolkits too though.

[Quackdoc]

... The compositor, also known as Mutter, Plasma, et cetera.

Here is a radical idea; how about developing an opt-in extension protocol for the compositor itself that allows the compositor to share this information for select applications as specified by the user, then?

Sure, that's not how we did it in the olden days. Sure, it is more complicated to set up. OTOH, the compositor remains in full control and you can just piggy back on the work in the compositor.

Have you even tried talking to the compositor devs instead of the Wayland devs? Or base your work on something simpler like, say, the SWC library? Sounds more to me you don't understand the new options and is stuck in the ways it USED to work.

because needing to add this protocol to every compositor is a shit show, gnome as already stated they aren't interested in implementing non official protocols. and currently we for compositors we have off the top of my head

• kwin
• mutter
• wlroots
• smithay
• weston

which means you need to add that opt-in extension to at least the top 4 being what most compositors are going to be made from. this means you need to get all of these guys to agree on a single protocol, which has proved impossible. just ask for idle inhibit or wlr layers on gnome, go on, do it. then realize how stupid you sound Because as said before, people already tried.

and no, "just don't support X compositor that doesn't have support for Y protocol" is not a good solution.

[wertigon]

No, as in the people I talked to either implied or outright said that they don't believe that "in the era of Wayland", there's a place for applications other than the compositor itself to be able to gain access to that kind of information.

... The compositor, also known as Mutter, Plasma, et cetera.

Here is a radical idea; how about developing an opt-in extension protocol for the compositor itself that allows the compositor to share this information for select applications as specified by the user, then?

Sure, that's not how we did it in the olden days. Sure, it is more complicated to set up. OTOH, the compositor remains in full control and you can just piggy back on the work in the compositor.

Have you even tried talking to the compositor devs instead of the Wayland devs? Or base your work on something simpler like, say, the SWC library? Sounds more to me you don't understand the new options and is stuck in the ways it USED to work.

[ssokolow]

seems pretty clear you are still expecting this problem to be solved by Wayland devs, which is about as useful as asking the fire department to hunt down the guy that stole your car.

No, as in the people I talked to either implied or outright said that they don't believe that "in the era of Wayland", there's a place for applications other than the compositor itself to be able to gain access to that kind of information.

...and that's why I think they're idealistic fools because we're already seeing applications circumvent the Wayland security model in order to provide users the features they desire. (eg. by asking users to grant permission for applications to synthesize keyboard input via the kernel-level uinput APIs, which obviously can't present granny-friendly per-application GUI permission prompts.)

When users need functionality, and application developers are determined to meet that need, you can't prevent them from achieving it on an open-source operating system... you can only choose whether or not you force them to smash your pretty security model to achieve it.

[Quackdoc]

Sadly you do not appear to possess the intelligence capable of understanding that Wayland is not the same thing as the XDG protocol. Some features overlap, others do not.

the entire point is because you said that "And this should be in the Wayland protocol because why?" which implies that he even remotely implied that he believed it should be in wayland, despite the fact that he explicitly linked the XDG protocol to add the feature, as you said "Wayland is not the same thing as the XDG protocol" something you seem to have completely glossed over when making the assumption.