Originally posted by TemplarGR
View Post
Announcement
Collapse
No announcement yet.
SDL3 Begins Dumping A Lot Of Old Code: GLES1, OS/2, DirectFB, WinRT, NaCl & More
Collapse
X
-
-
Originally posted by wertigon View PostHere 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.
Originally posted by wertigon View PostCrash 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
Originally posted by wertigon View PostPatches welcome, as always.
Leave a comment:
-
Originally posted by ssokolow View PostMy 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.
Originally posted by ssokolow View PostHell, 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.
Patches welcome, as always.
Leave a comment:
-
Originally posted by wertigon View Post
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.
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.Last edited by ssokolow; 28 November 2022, 04:23 PM.
- Likes 1
Leave a comment:
-
Originally posted by Quackdoc View Postmaking 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.
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.
Leave a comment:
-
Originally posted by wertigon View PostIs 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.
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.
- Likes 1
Leave a comment:
-
Originally posted by Quackdoc View Post
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
and no, "just don't support X compositor that doesn't have support for Y protocol" is not a good solution.
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.
Leave a comment:
-
Originally posted by wertigon View Post
... 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.- kwin
- mutter
- wlroots
- smithay
- weston
and no, "just don't support X compositor that doesn't have support for Y protocol" is not a good solution.
- Likes 1
Leave a comment:
-
Originally posted by ssokolow View Post
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.
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.Last edited by wertigon; 28 November 2022, 06:01 AM.
Leave a comment:
-
Originally posted by wertigon View Postseems 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.
...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.Last edited by ssokolow; 28 November 2022, 12:17 AM.
Leave a comment:
Leave a comment: