Originally posted by s_j_newbury
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 david-nk View PostReading this thread is unreal. Not just one misguided person, but a whole bunch of people acting as if the last distro using X11 was released sometime 15 years ago... except no, X11 is still universally used everywhere. The mere idea of dropping X11 support anywhere in the next decade is ridiculous.
Comment
-
Originally posted by ryao View Post
Why are you prefacing a joke with “in all seriousness”? X11 is widely deployed. You might as well suggest dropping Linux support. It would be just as absurd.
Yes, it would mean SDL3 isn't the library you're looking for if you want your application to work on all SDL2 supported platforms just by switching out the SDL_VIDEODRIVER, that's probably "not a good thing" unless it enables SDL3 to offer something really compelling. I can't imagine a lot of SDL users being happy with that, but they could keep SDL2 around for legacy platforms, and perhaps write SDL3 platform drivers for SDL2 so they only have to maintain SDL3 supported platform code paths in one place, a bit like what happened with libinput and Xorg input drivers, or Pulseaudio and Pipewire.
I'm not convinced it is worth it, but it isn't my call. I'd preferably like it to have enough abstraction and flexibility to support any platforms I'm interested in, and would extend that to those with any significant user base. That would probably include OS/2 and WinRT, and definitely X11.
Comment
-
Originally posted by timofonic View PostWayland [...] needs to have not only feature parity with XOrg, but even more features usually done by tons of hacks and dirty userland taking advantage of XOrg extremely patched up design.
Anyone thinking feature parity is essential or even desirable has not understood the problem space, and anyone that thinks Wayland won't come anytime soon has the same cognitive dissonance as the people convinced we'll still happily pay good money for a petrol car in 2030.Last edited by wertigon; 25 November 2022, 01:54 PM.
- Likes 1
Comment
-
Originally posted by s_j_newbury View Post
Dropping legacy support in SDL3 seems to be the reason they're going with a major version bump. I'm generally very much in favour of maintaining legacy support, if for no other reason I personally keep a lot of old hardware in use! It's one of the big reasons I also use Gentoo. But, if they want a clean break with legacy cruftiness, X11 is a big part of that.
Yes, it would mean SDL3 isn't the library you're looking for if you want your application to work on all SDL2 supported platforms just by switching out the SDL_VIDEODRIVER, that's probably "not a good thing" unless it enables SDL3 to offer something really compelling. I can't imagine a lot of SDL users being happy with that, but they could keep SDL2 around for legacy platforms, and perhaps write SDL3 platform drivers for SDL2 so they only have to maintain SDL3 supported platform code paths in one place, a bit like what happened with libinput and Xorg input drivers, or Pulseaudio and Pipewire.
I'm not convinced it is worth it, but it isn't my call. I'd preferably like it to have enough abstraction and flexibility to support any platforms I'm interested in, and would extend that to those with any significant user base. That would probably include OS/2 and WinRT, and definitely X11.
It is only called cruft when nobody uses it.
- Likes 1
Comment
-
Originally posted by wertigon View Post
O really? Why would you ever want things like input device drivers (better handled with UDev), network support (better with pipewire for both raster and vector) or other obscure features, many which have been broken for YEARS and noone complaining about it, in your display protocol?
Anyone thinking feature parity is essential or even desirable has not understood the problem space, and anyone that thinks Wayland won't come anytime soon has the same cognitive dissonance as the people convinced we'll still happily pay good money for a petrol car in 2030.
Stuff like DE-independent support for allowing time-tracking apps to retrieve the name of the currently focused window which is currently unimplemented by the compositors and not possible for users to retrofit due to the security model. (That's actually one feature that's keeping me on X11.)
- Likes 2
Comment
-
Originally posted by ssokolow View PostStuff like DE-independent support for allowing time-tracking apps to retrieve the name of the currently focused window which is currently unimplemented by the compositors and not possible for users to retrofit due to the security model. (That's actually one feature that's keeping me on X11.)
This sounds like something similar, a use case that can be better and more securely achieved using different tools.
Tried contacting some systemd developers about this, instead of uselessly complaing on a web forum about it? They are quite friendly, only tend to bite 5% of the time 🙂
Comment
-
Originally posted by wertigon View Post
A few years back I was using a raw socker to filter some TCP traffic for years. Then I realized a systemd service combined with nfTables was a much, much better fit for that.
This sounds like something similar, a use case that can be better and more securely achieved using different tools.
Tried contacting some systemd developers about this, instead of uselessly complaing on a web forum about it? They are quite friendly, only tend to bite 5% of the time 🙂- The purpose of using the window titles is to distinguish things like which LibreOffice document you're working on or which web page you're viewing without needing to write and install a patch or plugin for each and every application... assuming you even can, given that some applications are closed-source and lacking plugin APIs.
- macOS classifies the equivalent API under "accessibility" and it's apparently important for assistive technologies that need to be able to behave differently on some applications than others, given how many things are migrating into being web apps (eg. YouTube, Google Docs, etc.)
- Many applications already exist which work this way, and so you'll have to convince them to port to whatever you propose. (Examples given include time trackers, clipboard managers that support omitting stuff from applications blacklisted as sensitive (eg. password managers), accessibility applications, etc.)
- I'm one of several people sitting on this xdg-desktop-portal issue because the portals system is the most natural place for such functionality to be reconciled with the Wayland security model in a desktop-agnostic manner.
- Likes 1
Comment
-
Originally posted by ssokolow View Post- I'm one of several people sitting on this xdg-desktop-portal issue because the portals system is the most natural place for such functionality to be reconciled with the Wayland security model in a desktop-agnostic manner.
the wayland is full of stuff like this, and is the single largest reason why I think linux will never be ready for the general desktop user. since we are pushing harder and harder to a platform that cares more about security then actually being usable.
I can understand wayland protocols not implementing something like this sure. but the people saying that XDG shouldn't implement it can only be interpreted as "The user is too stupid to give them the capability of allowing this". despite it being a quite nice feature to have.
- Likes 1
Comment
Comment