Announcement

Collapse
No announcement yet.

Wayland's Weston Compositor Introduces Kiosk/Fullscreen Shell

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

  • #11
    Facts are not trolling. But whether what you're spouting is a "fact" is a matter of debate. You did exactly what I said you would, pin the problem on compositor devs rather than the state and completeness of the protocol. And you did nothing to address the main issue, which is that it isn't just about the compositor, but that you're forced to also take the entire environment that comes with it. How about that fact, hmm?

    Comment


    • #12
      Originally posted by Gusar View Post
      Good post oiaohm, you've listed a few genuine weak points of X11. But that still does not address the issues of Wayland, issues that do have solutions in X - lack of interoperability, requiring tight coupling between compositor and environment - panel/task manager, desktop manager, screen configuration, input configuration, etc, etc. In Wayland, input and screen configuration is limited by what the compositor devs decided to expose in their environment's configuration panel. There's no xinput or xrandr, environment-independent command-line tools that expose *everything* the underlying protocol is capable of.
      Xinput is a good question. Input is one of these areas that have changed a lot over the years. In fact complete access to xinput you in fact want to take back. Lets say you have 2 applications with Xinput register to receive the same short cut key what one gets the short cut. Under Xinput with X11 it is serous-ally luck of the draw its everything between first one loaded or second one loaded to o my god both yes generally first loaded wins but its not absolute certainty. Next with libinput lots of your input stuff has been moved to udev controlled there are a lot of xinput options that are now no-ops..

      Wayland highly restrictive base design on input is correct as it fixes up these short cut issues even allowing short cuts to be properly changed by the compositor based on active window instead of the current do you fill lucky punk with Xinput.

      Xrandr is also a good way to cause many different X11 compositors to crash by changing to a mode they don't support so this need to be changed to compositor controlled so compositor can veto a gpu change they don't support so users interface does not crash. Yes the X11 design of Xrandr that it can go straight past the compositor is a really bad thing.

      Originally posted by Gusar View Post
      Then, only recently have wlroots devs written a protocol that allows communication between window management and panels/task managers, so that you're not limited to the panel/task manager that the compositor is coupled with. Now the question becomes, will the protocol see widespread adoption?.
      X11 protocol did not come at first with a panel/task manager protocol as first. Next you have never read the X11 protocol implementation either instead just presume it working right I guess. Yes you have just pointed to another broken area of X11. X11 panel implementation is stupid dangerous. Application gets to tell X11 what PID(process id) number the application is. << Read that. So lets say a application decided to be a ass an tell X11 server that its PID number is the Windows manager/X11 compositor instead of it own now you close the application by panel under X11 get ready to be logged out because you just killed your X11 windows manager/compositor instead.

      The section X11 protocol that allowed using third party panel at all was added 15 years after X11 protocol creation and it still designed horrible wrong. Cause of X11 protocol for panels being design horrible wrong is attempting to be totally platform neutral.

      Wayland protocol has in fact implemented at this point all of X11 protocols features that worked properly and safely. Every other missing feature need to go back to the drawing board and be redone some other way as the old X11 method is broken to hell.

      Most people are clueless that when they are listing missing features from Wayland that X11 has they are also in fact listing areas of X11 that causes crashes and is designed poorly.

      There is more than a few X11 weak points if you pick a protocol section in use on your current day Linux desktop at random from X11 protocol you have a 70% under closer inspection that is defective. X11 protocol is more weak points than good stuff. Restoring all the functionality of X11 in way that is safe and stable is not a fast or simple process. Yes wayland protocol to redo the complete lot was the last thing the X.org developers wanted to-do they just got the point that they had worked out too much of the X11 protocol is broken and if you fix the X11 protocol server side the existing X11 applications will break.

      Its horrible right to here that wayland protocol is not a optional thing Wayland work is really part of something that must be done. Of course getting all the features added back to Wayland protocol or added in as third party items is going to take time. Some of the add in like the pipewire screen capture will work under X11 so allow masking over some of the X11 design defects but even if you mask over everywhere you can with X11 you will not fix that the core is basically busted. So its really wayland or bust at this stage if people don't like wayland they will have to implement some other alternative to Wayland as X11 protocol is serous-ally broken to the point of no repair is possible.

      Of course we could see like a case were the wlroot based stuff forks away from the core wayland stuff and we have a fight out between core Wayland and wlroot stuff to see what future winner we have. Even a fight like that is going to land us with something better designed than X11 protocol.

      Biggest problem X11 protocol is a collection of parts over the years that developers added what ever they felt like without considering future or if what they were doing was secure now you have a stack of applications depending on X11 protocol behaving badly. End users have got use to using X11 in ways that they don't walk into the defects of the protocol most of the time.

      Have you had the one where copy paste under X11 gets stuck because some application has locked the copy paste buffer before? Yes there are a lot of minor bugs like this one that X11 protocol allows to happen that users end up just learning to work around when they hit them as well that are fixed in wayland.

      Comment


      • #13
        You know your stuff oiaohm, that was a fascinating read. You're aware of issues and strengths of both windowing systems, unlike 144Hz's blind "Wayland/Gnome is perfect" fanboyism.

        Of course we could see like a case were the wlroot based stuff forks away from the core wayland stuff and we have a fight out between core Wayland and wlroot stuff to see what future winner we have.
        Something like that is already the case. Only wlroots developers seem to be interested in creating protocols for things that are missing, with KDE devs generally being on board, but Gnome has no interest in cooperating.

        Comment


        • #14
          Gusar If you disagree with the current Wayland scope and the current Wayland steering group then move on and repeat all the mistakes from the past.

          Comment


          • #15
            Originally posted by 144Hz View Post
            Gusar If you disagree with the current Wayland scope and the current Wayland steering group then move on and repeat all the mistakes from the past.
            Like "Scripting is a mistake"? Wow, what a terrible ideology you have.

            Comment


            • #16
              Originally posted by tildearrow View Post
              Like "Scripting is a mistake"? Wow, what a terrible ideology you have.
              https://gitlab.gnome.org/ofourdan/gn...nytail-daemon/

              The reality is wayland applications are script-able but it requires different way of doing things. Yes remotedesktop api usage instead of XTest. Also using the screencast capture instead of direct screen capture.

              XTest in X11 could and up delivering a scripted click to a unattended application its been a documented issue using dogtail to script applications for a long time.

              Tildearrow the missing features from wayland like it or not are all broken. Yes windows and OS X script control of applications also have the defect of being able to deliver clicks and key-presses to the wrong application.

              Lot of ways even the way that can be done for wayland is not ideal to script applications but it no worse than X11 offered the big difference is the new method you need authorisation to fake inputs or read screen so some random application cannot just do it.

              Allowing any random application to be able to read the screen or fake input is a mistake.

              This is another case where this stuff is done over dbus not wayland with wayland compositors because this stuff need authorisation.

              Comment


              • #17
                Originally posted by oiaohm View Post

                https://gitlab.gnome.org/ofourdan/gn...nytail-daemon/

                The reality is wayland applications are script-able but it requires different way of doing things. Yes remotedesktop api usage instead of XTest. Also using the screencast capture instead of direct screen capture.
                Bloat

                So to script in Wayland compositors I have to train an AI to guess where is the window at?

                Originally posted by oiaohm View Post
                XTest in X11 could and up delivering a scripted click to a unattended application its been a documented issue using dogtail to script applications for a long time.
                Originally posted by oiaohm View Post
                Tildearrow the missing features from wayland like it or not are all broken. Yes windows and OS X script control of applications also have the defect of being able to deliver clicks and key-presses to the wrong application.
                Oiaohm that is your opinion. At least they have standard ways, while in our case we have to do it per-compositor. Except AT-SPI2

                Originally posted by oiaohm View Post
                Lot of ways even the way that can be done for wayland is not ideal to script applications but it no worse than X11 offered the big difference is the new method you need authorisation to fake inputs or read screen so some random application cannot just do it.
                Yes

                Originally posted by oiaohm View Post
                Allowing any random application to be able to read the screen or fake input is a mistake.
                Allowing any random application to be able to read the screen or fake input with the user's consent is not a mistake however.

                Originally posted by oiaohm View Post
                This is another case where this stuff is done over dbus not wayland with wayland compositors because this stuff need authorisation.
                Yes. Now hope that dbus is fast and lightweight and the compositors implement it.

                Come on where is my dbus c++. I have to bring a whole Qt or GTK or tie to systemd for it. Otherwise I get lost in the realm of endless underscores and confusion with libdbus.

                Comment


                • #18
                  Originally posted by tildearrow View Post
                  So to script in Wayland compositors I have to train an AI to guess where is the window at?
                  https://gitlab.gnome.org/ofourdan/gn...nytail-daemon/
                  Code:
                  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.
                  So no you are not using a AI to get where a window is at. Turns out the screencast interface can answer the global coordinates of a window under Wayland.

                  Originally posted by tildearrow View Post
                  Oiaohm that is your opinion. At least they have standard ways, while in our case we have to do it per-compositor. Except AT-SPI2
                  Please note in that line that called the AT-SPI2 interface ATK same thing just gnome implementation. Between the remote desktop interface the screencapture interface and the AT-SPI2 you can recreate something as bad as the old XTest interface. So there are 3 interfaces that quite a few wayland compositors implement that but this is really not the best way as it still broken. Yes you complain this is bloat this is a good thing to be calling bloat since just like XTest it does not work right for script control 100 percent of the time.

                  Reality is the idea that you have todo this per compositor is wrong.

                  Originally posted by tildearrow View Post
                  Allowing any random application to be able to read the screen or fake input with the user's consent is not a mistake however.
                  Most likely this is a mistake as well. There is a reason why wayland only is giving applications local coordinates instead of global ones that results in ATK/AT-SPI2 information being local coordinates.

                  Start thinking with wayland you don't really need to fake global input as you have to under X11. Instead faking input to individual applications would be better in most cases. Same with reading screen lot of cases you want to read a window not a screen. Remember multi windows on screen could be on top of the window you are reading screen to attempt to see of the application you are wanting to control.

                  Originally posted by tildearrow View Post
                  Yes. Now hope that dbus is fast and lightweight and the compositors implement it.
                  This is that you have missed something.
                  https://gitlab.freedesktop.org/mstoeckl/waypipe/
                  Wayland protocol supports compositor on top of compositor in a never ending stacking. So in theory not all compositors of Wayland have to implement everything. But no one has been coding up proxy compositors to extend features.

                  Lets say the application you wanted to control you had a proxy compositor between the application and the display compositor. This proxy compositor would not know global coordinates only local coordinates and only need to interface with AT-SPI2 for information. Local coordinates is enough to fake input to applications the wayland design so the proxy can fake input.

                  This does have some advantages 1 the proxy could intentionally block input to application while mid remote control task. 2 window being moved on screen by display compositor is going to have zero effect on the input going the application. Windows popping over the top are also going to have zero effect on the input going to the application.

                  The proxy can read the output window no matter what is stacked on top. So now you can remote application by script and go off and do something else without risking disrupting the script controlling the application.

                  So the proxy wayland compositor route would give you script-able control over an application that 100 percent behaves and allow the application being controlled by script to pushed to background while it does it thing.

                  Lot of ways I just wish the AT-SPI2 standard would add fake input since we now have local coordinates with wayland and you really don't need to know where the application is on screen to fake input any more.

                  Originally posted by tildearrow View Post
                  Come on where is my dbus c++. I have to bring a whole Qt or GTK or tie to systemd for it. Otherwise I get lost in the realm of endless underscores and confusion with libdbus.
                  Really to use AT-SPI2 to get information to in fact control X11 applications by Xtest you have to interface with dbus anyhow. So this is a universal problem you have to over come not something special wayland causes.

                  You never considered the idea of a proxy wayland compositor did you to allow you to script control wayland applications. Wayland standard does have a method included to application control in generic way just it means making a proxy compositor and starting application you want to control with proxy compositor. Now if you don't like the proxy compositor route its the screencast and remote-desktop API route over dbus. If you don't like either its then like extend AT-SPI2 to allow input.

                  I really do think wayland offers up enough options. Just they are different options to the old XTest and Windows and OS X broken methods.

                  Comment


                  • #19
                    tildearrow Enjoy AT-SPI2. Enjoy Pipewire. You know who made it and why they made it.

                    Comment


                    • #20
                      Originally posted by 144Hz View Post
                      tildearrow Enjoy AT-SPI2. Enjoy Pipewire. You know who made it and why they made it.
                      Stop.

                      Comment

                      Working...
                      X