Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by s_j_newbury View Post

    In seriousness, if they're wanting to remove legacy code, it doesn't get any more legacy than X11. There's always old releases of SDL for legacy software, some never got updated from SDL1, and much of it still works even with SDL2/Wayland with the wrapper, as long as direct X11 calls aren't made. SDL never officially supported the use of mixed windowing system calls + SDL, if you're using SDL, it is supposed to be an abstraction. They've always been quite good at implementing new features as needed to support whatever edge cases might result in needing to write that kind of hack.
    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.
    Last edited by ryao; 24 November 2022, 07:35 PM.

    Comment


    • #32
      It is odd that they are removing DirectFB support given that it is undergoing a revival:

      https://github.com/directfb2/DirectFB2

      Comment


      • #33
        Originally posted by david-nk View Post
        Reading 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.
        there are lots of people pushing for X to die, I could see it happening even in the next 5 years if wayland protocol development finds a way to speed up

        Comment


        • #34
          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.
          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.

          Comment


          • #35
            Originally posted by timofonic View Post
            Wayland [...] 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.
            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.
            Last edited by wertigon; 25 November 2022, 01:54 PM.

            Comment


            • #36
              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.
              They are dropping things practically no one uses, not things that are in use everywhere. :/

              It is only called cruft when nobody uses it.

              Comment


              • #37
                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.
                I think, by "feature parity", they meant "the same features need to be possible, through any avenue", not "the Wayland compositor needs to be where those features are implemented".

                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.)

                Comment


                • #38
                  Originally posted by ssokolow View Post
                  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.)
                  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 🙂

                  Comment


                  • #39
                    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 🙂
                    1. 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.
                    2. 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.)
                    3. 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.)
                    4. 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.

                    Comment


                    • #40
                      Originally posted by ssokolow View Post
                      1. 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.
                      I love issues like this, because it perfectly represents the baffling mentality of the wayland ecosystem. this is absolutely one of those "this is a valid feature for accessibility reasons, but we don't care about those people, but you should use wayland anyways".

                      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.

                      Comment

                      Working...
                      X