Announcement

Collapse
No announcement yet.

Qt 6.6 Wayland Compositor Handoffs Look Promising For More Robust Experience

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

  • #31
    Originally posted by avis View Post

    And no one is talking about how Wayland is broken beyond repair if every toolkit for it must implement this feature specificially for it.
    Plasma on Wayland works at least using Intel + Kubuntu 23.04 + backports, with very minor inconveniences (https://bugreports.qt.io/browse/QTBUG-77182). The big problem comes when trying to automate things like sending keys to programs or reacting to what programs are showing. Other people wrote it better:

    AutoHotkey is a power user tool. Those are two APIs from it that a ton of users use to automate their workflows using smart scripts that require no input (other than get triggered):
    - https://www.autohotkey.com/docs/v1/lib/WinGetPos.htm
    - https://www.autohotkey.com/docs/v1/l...elGetColor.htm

    As you can clearly see, "spying" on another app's pixels or position is in no way malware and it's perfectly legit and valid use case.

    Windows, which is used by the vast majority of people who care about GUIs the most (not servers), allows this. So it's obviously far from insecure as paranoid guys from Wayland claim.
    -- Adapted from https://www.phoronix.com/forums/foru...45#post1372445

    There is more information on https://www.reddit.com/r/wayland/comments/85q78y/why_im_not_going_to_switch_to_wayland_yet/​

    Comment


    • #32
      Originally posted by Nth_man View Post
      AutoHotkey is a power user tool. Those are two APIs from it that a ton of users use to automate their workflows using smart scripts that require no input (other than get triggered):
      - https://www.autohotkey.com/docs/v1/lib/WinGetPos.htm
      - https://www.autohotkey.com/docs/v1/l...elGetColor.htm

      As you can clearly see, "spying" on another app's pixels or position is in no way malware and it's perfectly legit and valid use case.

      Windows, which is used by the vast majority of people who care about GUIs the most (not servers), allows this. So it's obviously far from insecure as paranoid guys from Wayland claim.
      Well, I use Robot Framework at work, for testing purposes. Would be great if I had a choice of the robot OS also with Wayland but sadly ATM we only test web and Windows applications.

      Comment


      • #33
        Originally posted by Nth_man View Post

        Plasma on Wayland works at least using Intel + Kubuntu 23.04 + backports, with very minor inconveniences (https://bugreports.qt.io/browse/QTBUG-77182). The big problem comes when trying to automate things like sending keys to programs or reacting to what programs are showing. Other people wrote it better:

        AutoHotkey is a power user tool. Those are two APIs from it that a ton of users use to automate their workflows using smart scripts that require no input (other than get triggered):
        - https://www.autohotkey.com/docs/v1/lib/WinGetPos.htm
        - https://www.autohotkey.com/docs/v1/l...elGetColor.htm

        As you can clearly see, "spying" on another app's pixels or position is in no way malware and it's perfectly legit and valid use case.

        Windows, which is used by the vast majority of people who care about GUIs the most (not servers), allows this. So it's obviously far from insecure as paranoid guys from Wayland claim.
        -- Adapted from https://www.phoronix.com/forums/foru...45#post1372445

        There is more information on https://www.reddit.com/r/wayland/comments/85q78y/why_im_not_going_to_switch_to_wayland_yet/​
        Excuse me, but it's not as paranoid from my point of view.

        I think this can be easily solved by assigning that stuff to a proper universal and mandatory Android-like permissions subsystem that complements *NIX ones and others. Simple as that.

        Cameras. Screen. Microphone. Keyboard. Mouse. Etc.

        Comment


        • #34
          Originally posted by Nth_man View Post
          The big problem comes when trying to automate things like sending keys to programs or reacting to what programs are showing. Other people wrote it better:

          AutoHotkey is a power user tool. Those are two APIs from it that a ton of users use to automate their workflows using smart scripts that require no input (other than get triggered):
          - https://www.autohotkey.com/docs/v1/lib/WinGetPos.htm
          - https://www.autohotkey.com/docs/v1/l...elGetColor.htm

          Also, Wayland does not expose global coordinates, and ATK will return local coordinates of the various application widgets on Wayland, this is where the RecordWindow method from screencast can be used, as it will translate global coordinates into surface relative coordinates.
          There is another way to do those APIs by xdg-portal yes the ponytail code proved it was possible quite some time ago.

          Originally posted by Nth_man View Post
          As you can clearly see, "spying" on another app's pixels or position is in no way malware and it's perfectly legit and valid use case.
          xdg-portal you have to authorization check. Valid use case should be able to validate themselves right??

          https://www.phoronix.com/news/KDE-XWaylandVideoBridge yes the same way X11 applications under X11 have been allowed by this to use their old screen capture measures.

          Nth_man perfectly legal and valid use case does not magically equal the use case should valid be able to function without requiring authorization.

          Please note I am not saying this area does not need work. The reality it does but when dogtail with ponytail got everything AutoHotkey can do working with wayland that not really example of impossible to work is it.

          Heck someone does little more work with XwaylandVideoBridge to allow input emulation and autohotkey using X11 could work on wayland applications authorization done by XwaylandVideoBridge.



          Comment


          • #35
            This is a nice example of Wayland pulling away from X.

            Comment


            • #36
              Originally posted by mxan View Post
              15 years into Wayland’s existence and finally we won’t lose all our work when the compositor crashes.

              Oh wait, only one desktop and only one toolkit can do it, so the entire rest of the Linux app and desktop ecosystem misses out. Turns out, Wayland’s uselessly tiny core protocol wasn’t such a good idea after all, neither was designing the protocol in such a way that mandates putting the display server, window manger and compositor into one giant monolithic process. Reminds me a bit of Windows 98…

              In case people forgot, X11 window managers run as just another client like any other application, so they have always been able to be cleanly restarted without your apps even noticing. Many of them can also be completely swapped out for another one during runtime! This is something “ancient” X11 had since the beginning and Wayland is only just catching up on.

              Maybe next year, Wayland. Maybe next year.
              Xorg can't keep your session if it crashes, what are you talking about.

              No different with Wayland here, if your display server crashes your session goes, except Wayland isn't a drawing API and has a far simplified API, more akin to other platforms which have been able to do this for decades now, so its easier to rebuild a state if the display server crashes.

              You want your display server to be compositing if you care about latency and no tearing.

              Comment


              • #37
                Originally posted by Nth_man View Post

                Plasma on Wayland works at least using Intel + Kubuntu 23.04 + backports, with very minor inconveniences (https://bugreports.qt.io/browse/QTBUG-77182). The big problem comes when trying to automate things like sending keys to programs or reacting to what programs are showing. Other people wrote it better:

                AutoHotkey is a power user tool. Those are two APIs from it that a ton of users use to automate their workflows using smart scripts that require no input (other than get triggered):
                - https://www.autohotkey.com/docs/v1/lib/WinGetPos.htm
                - https://www.autohotkey.com/docs/v1/l...elGetColor.htm

                As you can clearly see, "spying" on another app's pixels or position is in no way malware and it's perfectly legit and valid use case.

                Windows, which is used by the vast majority of people who care about GUIs the most (not servers), allows this. So it's obviously far from insecure as paranoid guys from Wayland claim.
                -- Adapted from https://www.phoronix.com/forums/foru...45#post1372445

                There is more information on https://www.reddit.com/r/wayland/comments/85q78y/why_im_not_going_to_switch_to_wayland_yet/​
                Try getting a windows application to touch applications running as another user or the UAC prompt.

                Comment


                • #38
                  Originally posted by Nth_man View Post
                  Windows, which is used by the vast majority of people [so] it's obviously far from insecure as paranoid guys from Wayland claim.
                  Seriously? Is Windows now the bar for being secure? Or if the majority use it a measure for secure?

                  C'mon, we did better (see the NSA_KEY debacle in Windows; Linux could have never had such a backdoor), we're doing better (when it comes to servers for secure systems Linux is the benchmark) and will do better: Wayland.

                  Comment


                  • #39
                    Originally posted by MrCooper View Post
                    This is a nice example of Wayland pulling away from X.
                    X applications survive just fine when the window manager crashes Not X's fault Wayland mixed the window manager and the graphics server (client) together.

                    Comment


                    • #40
                      Originally posted by carewolf View Post
                      X applications survive just fine when the window manager crashes Not X's fault Wayland mixed the window manager and the graphics server (client) together.
                      But X11 applications don't naturally survive when the X11 server fails. Not all wayland implementations have in fact mixed windows manger and compositor into one MIR is one of the early examples of this.

                      xpra has been used with X11 remote for a long time as well.

                      Really look at your x11 a little more carefully.

                      You have X11 windows manager + X11 compositor + X11 Server(display server) in a lot of environments. . X11 Server locks up frozen desktop, X11 compositor locks up frozen desktop. X11 windows manager crash control of desktop can be gone.

                      Reality existing X11 has too many moving parts those lock ups of X11 compositor and X11 server can both happen due to miss resource allocation between processors.

                      Wayland joined 3 parts into one. Windows manager, compositor and display server at core protocol design. Also note that particular desktop environments had already joined the compositor and windows manager of X11 into a single process so making a windows manager crash kind a bit more fatal anyhow.

                      carewolf like it or not the old X11 layout had problems.

                      Good one for you if your X11 server has a memory leak how are you going to address it without losing your desktop applications?

                      Does the means to restart the windows manager really matter if you can restart the complete windows manager/compositor/display server as a single item without stopping applications?.

                      By the way if you go back to the early X11 documents X11 applications were meant to always have the means to disconnect from one X11 server and connect to a different one and that never got implemented. We are just seeing this robust stuff for Wayland in fact implementing stuff that was said should have been done in the first 2 years of X11 protocols existence.

                      Comment

                      Working...
                      X