Announcement

Collapse
No announcement yet.

The Ongoing Work For Native Wine Wayland Support

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

  • #31
    Originally posted by oiaohm View Post
    Why does Wayland protocol use relative positions. Turns out you need to perform less maths to get absolute position on monitor that way instead of using X11/Windows like absolute position.
    Possibly, but my reason for supporting relative positioning is different.

    Generally speaking, absolute positioninig takes control *away* from the user. And I don't like that.

    Relative positioning is advantagaous because it hides implementation details (of the compositor).

    To expand on "hiding implementation details", consider that an application that wants absolute position, has to answer:
    - on which monitor?
    - is it valid for current display mode?
    - out of bounds?
    - what if display resolution changes? what if DPI changes?
    - what if application abuses this feature by constantly moving windows around?
    - what if application refuses to work if it doesn't like it's position?
    - what if application abuses this feature for digital fingerprinting?
    - probably many other assumptions

    Comment


    • #32
      In fact, to better hide implementation details of the compositor and to better protect the user, I certainly wouldn't allow an application to even know the position of its windows.

      Therefore, my suggested "initial window position" extension for Wayland should not allow applications to set an arbitrary initial window position. Instead, Wayland should allow applications to "save" their current position, to be restored on the next application startup.

      Probably the best implemetation: Upon application's request, Wayland compositor encrypts application's current position (and perhaps some other data/options), and sends the encrypted data to the application. Next time the application starts, it returns the encrypted data to the compositor.
      Last edited by drastic; 26 October 2023, 01:54 PM.

      Comment


      • #33
        Originally posted by oiaohm View Post
        Its not that straight forwards. Why does Wayland protocol use relative positions. Turns out you need to perform less maths to get absolute position on monitor that way instead of using X11/Windows like absolute position.

        So there are a lot of cases where applications use absolute positions under Windows and X11 that just are waste of CPU time. Remember each monitor out is it own buffer with its own X and Y with its own origin point.

        Get the problem yet. The Absolute position virtual image people are use to is virtual construct with no relevance to modern day hardware. Heck it does not even have relevance on the early multi monitor hardware.
        You still seem to think apps must only care about themselves ("relative" positioning) while there's apps that people want to run that they want to control other apps (such as scripts), so they must know EVERYTHING. This is not a security flaw, it's a FEATURE for those apps/scripts.

        Also you must be joking with this kind of maths. This is stuff done in the order of nanoseconds. Less than microseconds.

        Comment


        • #34
          Originally posted by Weasel View Post
          (To oiaohm) You still seem to think apps must only care about themselves ("relative" positioning) while there's apps that people want to run that they want to control other apps (such as scripts), so they must know EVERYTHING. This is not a security flaw, it's a FEATURE for those apps/scripts.
          An interesting use case, though for a small minority of use-cases.

          Anyway, I have a solution for that one, too (for native Wayland, not WinE), which avoids most of the problems of absolute positioning. Technically, it uses absolute positioning, but grants it only to trusted OS utilities, not to every application. It is the "right" solution, but it is complex, so I'll skip it. The reason why noone wants to implement it is complexity.

          Therefore, not having absolute positioning is the right design, for most applications, in my opinion.

          Comment


          • #35
            Originally posted by drastic View Post

            Possibly, but my reason for supporting relative positioning is different.

            Generally speaking, absolute positioninig takes control *away* from the user. And I don't like that.

            Relative positioning is advantagaous because it hides implementation details (of the compositor).

            To expand on "hiding implementation details", consider that an application that wants absolute position, has to answer:
            - on which monitor?
            - is it valid for current display mode?
            - out of bounds?
            - what if display resolution changes? what if DPI changes?
            - what if application abuses this feature by constantly moving windows around?
            - what if application refuses to work if it doesn't like it's position?
            - what if application abuses this feature for digital fingerprinting?
            - probably many other assumptions
            Most applications indeed don't want to manage that complexity and should not, and for them relative positioning is fine, and it should be the default.

            But many of these concerns listed are not specific to absolute positioning.

            And preventing absolute positioning even for apps that want to handle it actually takes control away from the user.
            Just like screen sharing, it's not because the developers don't use it or don't see the need for themselves that it should not be implemented.

            Originally posted by oiaohm View Post
            Turns out you need to perform less maths to get absolute position on monitor that way instead of using X11/Windows like absolute position.

            So there are a lot of cases where applications use absolute positions under Windows and X11 that just are waste of CPU time. Remember each monitor out is it own buffer with its own X and Y with its own origin point.

            Get the problem yet. The Absolute position virtual image people are use to is virtual construct with no relevance to modern day hardware. Heck it does not even have relevance on the early multi monitor hardware.
            This is an implementation detail, and the worst reason to dismiss a feature request.
            The whole point of a program is to provide users practical value, not to optimize minor calculation details.
            Last edited by wagaf; 27 October 2023, 05:12 PM.

            Comment


            • #36
              Originally posted by wagaf View Post
              This is an implementation detail, and the worst reason to dismiss a feature request.
              The whole point of a program is to provide users practical value, not to optimize minor calculation details.
              No it not. Protocols are all about implementation details.

              More maths to perform a task also equals more areas for for sync and math errors.

              Classic absolute position maths problem
              Following is what you find most applications on Windows and X11 in fact doing.
              1) Application gets Main Windows position in virtual image absolute position.
              2) Application adds relative location to Windows position.
              3) Application used value to pop up window.

              What happens lets say if the main window is moved between 1 and 3. That right that what causes the case of popup window no longer appearing above the application that created it. Yes you can have minimized the application under windows and X11 but then end up click on it pop up because it appear over the top of the application you have now switched to.

              The reality here is majority of X11/Windows application in existence are attempting to emulate relative position on virtual image based absolute position leading to a repeating set of bugs.

              Absolute position where the application in fact is intentionally using absolute position because it needs it turns out to be rare. Majority Applications under X11/Windows use absolute position because there is no good relative position API/ABI on those platforms.

              Yes to work around math/sync issues with X11/Windows based absolute position doing relative positions as you find in most X11/Windows applications the logical positioning with the top corner of the main window being 0.0 is correct answer in 90% of cases. Basically relative position the application you can counter maths and sync errors. The correct answer for 90%+ of all X11/Windows applications is don't use absolute positioning because by using it you are exposing user to math and sync errors caused by application attempting to-do relative position on top of absolute position.

              Yes it known 9 in 10 applications don't use absolute position to in fact do absolute position they are just using absolute position to emulate relative position.

              Yes 90%+ Some numbers say 95%+ of all applications should not be given absolute position even that they coded to use absolute position due to the bugs from them attempting to-do relative position on absolute position.

              Lot of ways applications that in fact need absolute position for the task they perform do need to be treated as a special case.​ X11 and Windows bugs around absolute position clearly show this.

              Something wine developers will tell you is they are using heuristic to work out what owns to what. Due to Windows and X11 API being absolute position dominated there is no clean link that this window that is now created should be relative positioned to the main window or anything else.

              This is another reason why Wayland developers are like we don't want to give application developers absolute position because they see that it results in applications not giving compositors enough information on what is related to what to allow windows to be moved around correctly.

              The deeper you go into this the more you work out we don't want image base absolute positioning.

              What makes more sense is anchor base relative positioning with special permissions required to get a physical absolute position. Developers need to be discouraged from using absolute position when the operation they are doing is best served by relative positioning.

              The problem here people say we need absolute position for X application then Wayland developer looks at X application an goes no you don't that a buggy absolute position application that need to be given only relative position data to fix the bugs in the application. 90%+ of the examples you could attempt to pick for absolute position turn out to be examples why you should not give applications absolute position.

              The math/sync issues with relative position on virtual image absolute position is a counter case against implementing absolute position.

              I would say in general applications should not be given absolute position.

              Remember you said by default to give applications relative position this in fact include 90%+ of applications already coded to use absolute position under X11 and Windows.

              Originally posted by wagaf View Post
              And preventing absolute positioning even for apps that want to handle it actually takes control away from the user.​

              That the catch. With the known bugs in applications that can believe they can handle absolute positioning the user need to be able block application from having absolute position if the application turns out to be buggy and 90% of existing X11 and Windows applications are buggy you can pick it up moving windows around and pop up turning up in the wrong places.

              So its not just if applications want to handle absolute position its also if application can use absolute position correctly.

              Taking control away from user is a serous one. User moves window out way to use application behind it but then as they attempt to use the application behind a pop up appears from the application they moved that they click on and cause some action they never intended to-do to happen so stole control from user due to bug. This is the one of the bugs of doing relative position emulation on absolute position in application instead of using a platform provided relative position solution(guess what Windows and X11 don't have).

              Miss behaving application using absolute position steal control from users. Users need to be in control if application can or cannot use absolute positioning with the default being no absolute positioning because that has the best chance of being right(over 90%) and at worse cause application not to work exactly right but will not cause control to be stolen from user.

              Comment


              • #37
                Originally posted by wagaf View Post
                And preventing absolute positioning even for apps that want to handle it actually takes control away from the user.
                Just like screen sharing, it's not because the developers don't use it or don't see the need for themselves that it should not be implemented.
                Absolute positioning grants control of the window position to a possibly untrusted application, therefore control has been taken away from the user.

                A feature not required, should not be implemented.

                From theoretical side, I don't see why would an application need absolute positioning, when it can just specify a larger size of the main window and fit the contents of "absolutely positioned" satellite windows into the main window.

                Therefore, I conclude that absolute positioning is not required. This conclusion is supported by a miniscule number or applications that actually use absolute positioning.

                Comment


                • #38
                  Originally posted by drastic View Post
                  An interesting use case, though for a small minority of use-cases.

                  Anyway, I have a solution for that one, too (for native Wayland, not WinE), which avoids most of the problems of absolute positioning. Technically, it uses absolute positioning, but grants it only to trusted OS utilities, not to every application. It is the "right" solution, but it is complex, so I'll skip it. The reason why noone wants to implement it is complexity.

                  Therefore, not having absolute positioning is the right design, for most applications, in my opinion.
                  And who the fuck decides which apps are allowed to or not?

                  Arcan uses a permission system using a virtual filesystem, so you can simply set the permissions as you want for yourself because ultimately YOU are the one who decides, not some corporate maintainer shithead. That's sane and better than X11, so I'm interested in it.

                  Crapland and the morons designing it is not.

                  Comment


                  • #39
                    Originally posted by drastic View Post
                    Absolute positioning grants control of the window position to a possibly untrusted application, therefore control has been taken away from the user.

                    A feature not required, should not be implemented.
                    So the user wrote that application. It's called a script. Now the user can't "control" his windows. You can't be this dense.

                    If you don't trust your apps sounds like a you problem.

                    This feature is absolutely required to allow the user control.

                    Crapland will forever remain a dogshit toy.

                    Comment


                    • #40
                      Originally posted by Weasel View Post
                      And who the fuck decides which apps are allowed to or not?
                      The user decides, of course.

                      The permissions for Wayland (including absolute positioning) and other OS permissions should be stored in a file of an "executable launcher" type. The user can create this file by double-clicking on the actual binary, which should cause the OS to run an "executable launcher setup" GUI application., where permissions can be ticked in checkboxes​

                      Originally posted by Weasel View Post
                      So the user wrote that application. It's called a script. Now the user can't "control" his windows. You can't be this dense.

                      If you don't trust your apps sounds like a you problem.

                      This feature is absolutely required to allow the user control.

                      Crapland will forever remain a dogshit toy.
                      You are confusing two different use-cases. One is running a normal application, and another is the user running his own scripts.

                      Of course, a user should be able to grant to a scipt a permission to set absolute window position. However, this is a niche use-case, so I guess that noone is rushing to implement it in Wayland.
                      Last edited by drastic; 28 October 2023, 03:44 PM.

                      Comment

                      Working...
                      X