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

  • #41
    Originally posted by ssokolow View Post
    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.
    Sounds like something that could be easily circumvented, especially if this is for surveillance purposes. A better way would be to use application fingerprinting in combination with systemd. It would achieve the same thing in a much more consistent manner.​

    If you really care about this, come up with a scheme within the framework that works instead of complaining that the framework does not support what you want to do. Also, see Nvidia being stuck on GBM/EGL issues for the longest time. Being stubborn about it does not help the bigger picture.

    Originally posted by Quackdoc View Post

    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".
    More like, the feature you want does not fall under the jurisdiction of the Wayland devs. What you want is compositor support for active application fingerprinting.

    Just because everyone else does it a certain way, does not necessarily mean that way is desirable. Windows and MacOS develop their OSes as closed source software; should XOrg and Wayland follow that model instead?

    Originally posted by Quackdoc View Post
    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.
    It is not users per se the security crowd does not trust; it is the programs they run. I feel very uncomfortable about XOrg having essentially a built in keylogger, and reimplementing that particular feature for "backwards compatibility" is just plain stupid.

    There is usually a sound middle ground but some features are just not feasible to keep. Like how AmigaOS had zero memory protection and that allowed speed at the cost of security. Should we reimplement that feature too? After all, a lot of programs depended on that feature back in the day...

    Comment


    • #42
      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.
      What are you smoking. Xorg works with udev and libinput.

      Comment


      • #43
        Originally posted by wertigon View Post

        Sounds like something that could be easily circumvented, especially if this is for surveillance purposes. A better way would be to use application fingerprinting in combination with systemd. It would achieve the same thing in a much more consistent manner.​

        If you really care about this, come up with a scheme within the framework that works instead of complaining that the framework does not support what you want to do. Also, see Nvidia being stuck on GBM/EGL issues for the longest time. Being stubborn about it does not help the bigger picture.
        Your interpretation of what's going on is so at odds with how I see things that it baffles me.

        "What I want to do" is "I'm on the autism spectrum (yes, professionally diagnosed) and have issues with executive dysfunction. Thus, I need to externalize keeping track of how much time I've spent on things, distinguishing different websites in the same browser, different document in the same editor, etc. I don't want to have to write a Firefox extension and a Chrome extension and a LibreOffice extension and a Vim plugin and ... to achieve that. People with physical disabilities also need similar ability so what are effectively specialized macro systems can synthesize input on a per-website basis. On desktop OSes that actually experience financial pressure from their user bases, this is accomplished by allowing assistive technologies elevated permissions to 'spy on' what the user is doing and/or 'forge input'."

        Since you're the one arguing for an analogue to "having a clipboard is a security risk, so let's replace it with something that doesn't allow applications to spy on each other", why don't you tell me how one is supposed to implement assistive software that needs to distinguish between YouTube and Google Docs in the same browser or between two documents within Google Docs and so on and inject input for macro-like behaviour without needing plugins for those specific things?

        ...because it sure seems to me that the only way to not tie yourself in knots is to do something like this, which is a "scheme" we've already "come up with" ages ago:

        1. Assistive software prompts for the ability to monitor window activation via an XDG portal.
        2. User clicks Allow in the privileged popup.
        3. Process is returned a handle/token which allows it to query such information.

        ...they just insist on refusing to accept that disabilities outside what they're ready to implement built-in support for (eg. cognitive disabilities) are a thing to avoid having to acknowledg that their perfect vision is inherently flawed.

        In general, Wayland has been suffering from refusing to live up to the promise they initially made that there would be a means for for trusted apps to be granted exclusive access to privileged APIs so the compositor didn't have to become a giant monolith of non-negotiable but prone-to-abuse functionality.​

        I believe we've started to see some assistive technologies, testing harnesses, etc. reinventing what they were doing on X.org either by hooking into kernel APIs like uinput below the Wayland compositor (thus missing the opportunity for a graphical permissions prompt) or abusing what accessibility APIs are available or writing a portability abstraction around compositor-proprietary or internal-use-only APIs, or just displaying a prominent message to the user saying something to the effect of "This feature cannot currently be supported under [compositor name]. Go poke the devs about it. If you can't wait, switch to a compositor that does allow it or switch to X11."

        Given that, and the whole "I can --replace my WM when it starts to glitch out after two or three weeks, or toggle KWin compositing off and on with a keyboard shortcut to work around a GPU driver bug, and it crashing won't take down X.org" thing, I'm going to stay on X.org for as long as I can since there doesn't seem to be much inertia on crash recovery either.

        Windows XP had crash recovery good enough that I never saw a graphics system crash kill more than a single DirectX or OpenGL application at a time and I really don't want to have to set up some franken-stack where I have kwin_wayland's X11 backend sitting on top of Xpra sitting on top of a kiosk-mode compositor to achieve the uptime I want.
        Last edited by ssokolow; 27 November 2022, 01:58 AM.

        Comment


        • #44
          Originally posted by ssokolow View Post
          ​Since you're the one arguing for an analogue to "having a clipboard is a security risk, so let's replace it with something that doesn't allow applications to spy on each other", why don't you tell me how one is supposed to implement assistive software that needs to distinguish between YouTube and Google Docs in the same browser or between two documents within Google Docs and so on and inject input for macro-like behaviour without needing plugins for those specific things?

          ...because it sure seems to me that the only way to not tie yourself in knots is to do something like this, which is a "scheme" we've already "come up with" ages ago:

          1. Assistive software prompts for the ability to monitor window activation via an XDG portal.
          2. User clicks Allow in the privileged popup.
          3. Process is returned a handle/token which allows it to query such information.
          ​
          ​
          And this should be in the Wayland protocol because why? Wayland is a dumb protocol to handle graphics buffers and blit those to the screen. This sounds like something that should be part of Mutter, Plasma, et cetera. Not Wayland.

          Please understand that the entire display model has changed for better and worse. It is now much more efficient, saves a lot more power, and is much simpler and more secure. Xorg is primarily based on ideas from the eighties; almost everything has changed from back then.

          Originally posted by ssokolow View Post
          ​​...they just insist on refusing to accept that disabilities outside what they're ready to implement built-in support for (eg. cognitive disabilities) are a thing to avoid having to acknowledg that their perfect vision is inherently flawed.

          In general, Wayland has been suffering from refusing to live up to the promise they initially made that there would be a means for for trusted apps to be granted exclusive access to privileged APIs so the compositor didn't have to become a giant monolith of non-negotiable but prone-to-abuse functionality.​
          ​
          I believe we've started to see some assistive technologies, testing harnesses, etc. reinventing what they were doing on X.org either by hooking into kernel APIs like uinput below the Wayland compositor (thus missing the opportunity for a graphical permissions prompt) or abusing what accessibility APIs are available or writing a portability abstraction around compositor-proprietary or internal-use-only APIs, or just displaying a prominent message to the user saying something to the effect of "This feature cannot currently be supported under [compositor name]. Go poke the devs about it. If you can't wait, switch to a compositor that does allow it or switch to X11."
          ​
          I repeat; Wayland is a dumb protocol to blit out and handle graphics buffers. Nothing more, nothing less. All the assistive features are the domain of, and part of Mutter, Plasma et cetera.

          Originally posted by ssokolow View Post
          ​Given that, and the whole "I can --replace my WM when it starts to glitch out after two or three weeks, or toggle KWin compositing off and on with a keyboard shortcut to work around a GPU driver bug, and it crashing won't take down X.org" thing, I'm going to stay on X.org for as long as I can since there doesn't seem to be much inertia on crash recovery either.​
          Sure, don't come crying in five years when the latest hardware won't support Xorg. But if you want things to change in a positive way, the only way is to actively involve yourself in the development. If you think the Wayland way is doing things the Wrong Way(tm), then help them do it the right way. Ask not what Open Source can do for you; Ask what you can do for Open Source!

          Comment


          • #45
            Originally posted by wertigon View Post
            But if you want things to change in a positive way, the only way is to actively involve yourself in the development. If you think the Wayland way is doing things the Wrong Way(tm), then help them do it the right way.
            Why bother trying to help if you are just going to get rejected? it would be better to just hold on to X, and wait, and if X dies before their is a suitable alternative, then thats the end of linux for people with accessibility issues, simple as that it will be time to move on. chromeOS isn't too bad, but that is it's own little segment that it sealed off for it'self, but that might be the only viable way forward for a lot of people who want to stick on linux.

            Comment


            • #46
              Originally posted by wertigon View Post
              And this should be in the Wayland protocol because why?
              I never said it had to be in the Wayland protocol and never intended to imply that.

              I'm simply saying that, until these problems are solved, there will remain legitimate demand for X11-based desktops over Wayland-based desktops.

              "WONTFIX because not part of the Wayland vision" doesn't magically make people not disabled. If X11 becomes unsupported before Wayland-based desktops implement something that solves these problems adequately (regardless of where in the stack they solve it) and I can't jury-rig a fix which breaks their beautiful artisanal security model to get my work done comfortably, then I'll be forced to move to some other platform.

              It's as simple as that. I have needs to be met and work to be done and their ivory tower idealism about how a desktop should be architected doesn't obviate those needs. I've filed the feature request (On the XDG portals repo because, as I've said, what's important is having a desktop-agnostic way to do it which harmonizes with the rest of the desired security model) and it's already been WONTFIX'd once before with an argument along the lines of "protecting granny from this is more important than providing accessibility for people with disabilities". I can't force them to accept any patches I'd write.
              Last edited by ssokolow; 27 November 2022, 08:28 AM.

              Comment


              • #47
                Originally posted by ssokolow View Post

                I never said it had to be in the Wayland protocol and never intended to imply that.
                Really? Because then you go on to say

                Originally posted by ssokolow View Post
                "WONTFIX because not part of the Wayland vision"
                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.

                ​You are clearly barking up the wrong tree here. That does not mean you do not have a problem; it just isn't a Wayland problem.

                You do have a problem with Mutter or Plasma though.

                Originally posted by ssokolow View Post
                I'm simply saying that, until these problems are solved, there will remain legitimate demand for X11-based desktops over Wayland-based desktops.
                ​
                Doubtful, Wayland is already better supported than XOrg and XOrg support will continue to dwindle. Features such as yours is pretty niche and there are no laws requiring support. Thanks to capitalism this all but guarantee this particular feature will disappear.

                What will happen is that you either fix the problem yourself or spend the next 20 years on a 2022 computer. GLHF with that! πŸ™‚

                ​It is not that the devs do not care; it is that there is too much work already.

                Comment


                • #48
                  Originally posted by wertigon View Post
                  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.
                  .
                  lol, really hope this is trolling considering it was explicitly the XDG protolcol tracker that was linked

                  Comment


                  • #49
                    Originally posted by Quackdoc View Post

                    lol, really hope this is trolling considering it was explicitly the XDG protolcol tracker that was linked
                    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.

                    Comment


                    • #50
                      Originally posted by wertigon View Post

                      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.

                      Comment

                      Working...
                      X