Announcement

Collapse
No announcement yet.

Qt 5.1 To Feature Improved Support For Wayland

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

  • #31
    Originally posted by smitty3268 View Post
    There is a way to tell that applications are not responding (or otherwise something like a busy cursor wouldn't be possible).

    It's entirely legal (and was proposed on the wayland list) for the compositor (Weston, KWin, etc.) to override the default appearance of the app in that case.

    That allows the compositor to stick custom menus, or draw it's own titlebar + buttons on top of the hung app, and the compositor is free to force close, minimize, help drag the window, etc. to it's hearts content.

    I don't have a link, but i'm sure you can google to find it if you want.
    I think it work something like that on windows. It works but at least on windows 7 it give some sort of alien feeling when the application misbehave. In linux today with client side yada a frozen application has a more native behaviour.

    Comment


    • #32
      Originally posted by smitty3268 View Post
      There is a way to tell that applications are not responding (or otherwise something like a busy cursor wouldn't be possible).
      Last time I looked they were supposed to be using polling to determine if windows were responsive or not (I believe this works the same way as in android).

      Comment


      • #33
        Originally posted by liam View Post
        Last time I looked they were supposed to be using polling to determine if windows were responsive or not (I believe this works the same way as in android).
        Yup, one of the worst techniques to do anything in computing.

        Just like sending commands is always better for network use than sending pixmaps (scraping pixels, VNC-style), polling is just about always the worst possible solution. But it's probably the only possible one, forced by Wayland's design, just like the pixel-scraping for networking (or the other proposition, per-toolkit thing which nobody will implement, or with which every toolkit will be incompatible with each other. Seriously, it's a huge advantage to have network support for *every* app by default, not just those compiled with toolkit foo.)

        Comment


        • #34
          Originally posted by curaga View Post
          Yup, one of the worst techniques to do anything in computing.

          Just like sending commands is always better for network use than sending pixmaps (scraping pixels, VNC-style), polling is just about always the worst possible solution. But it's probably the only possible one, forced by Wayland's design, just like the pixel-scraping for networking (or the other proposition, per-toolkit thing which nobody will implement, or with which every toolkit will be incompatible with each other. Seriously, it's a huge advantage to have network support for *every* app by default, not just those compiled with toolkit foo.)
          In Real Time Systems, where determinism is everything, polling is the preferred method and usually, as in safety critical systems, interrupts are forbidden.
          Last edited by newwen; 01-31-2013, 10:21 AM.

          Comment


          • #35
            In RT systems your app is usually the only important thing on the whole system. So its efficiency and monopolizing the cpu doesn't matter there.

            Comment


            • #36
              Originally posted by smitty3268 View Post
              Please do some research. This is just plain false.
              I did research. Wayland will only allow to kill unresponsive apps, not allow to minimize them.

              Comment


              • #37
                Originally posted by Awesomeness View Post
                I did research. Wayland will only allow to kill unresponsive apps, not allow to minimize them.
                Link, or please explain why the simple process above won't work.

                Comment


                • #38
                  Originally posted by curaga View Post
                  Yup, one of the worst techniques to do anything in computing.

                  Just like sending commands is always better for network use than sending pixmaps (scraping pixels, VNC-style), polling is just about always the worst possible solution. But it's probably the only possible one, forced by Wayland's design, just like the pixel-scraping for networking (or the other proposition, per-toolkit thing which nobody will implement, or with which every toolkit will be incompatible with each other. Seriously, it's a huge advantage to have network support for *every* app by default, not just those compiled with toolkit foo.)

                  I wouldn't argue about polling being a bad idea in general but sending commands isn't the best way for dumb retinal situations. Additionally, I don't know how well sending 3d commands would work from a performance POV.

                  I'm not sure polling is there only option. Heck I'm not sure they settled on it. Only that it seemed to be the path they were going to use first.


                  Hopefully there will be an fdo proposal made for sending drawing instructions across networks for those who want it but I'm fine with sending diffs.

                  Comment


                  • #39
                    Originally posted by smitty3268 View Post
                    Link, or please explain why the simple process above won't work.
                    I thought you were all so omniscient and yet do do not know that?
                    Check the Wayland video from the last Xorg conference, you genius! Michael recorded the entire conference and the videos were heavily featured and yet you missed that?

                    Comment


                    • #40
                      Originally posted by Awesomeness View Post
                      I did research. Wayland will only allow to kill unresponsive apps, not allow to minimize them.

                      ONLY kill unresponsive apps?
                      The display server that would later be called Weston has supported moving frozen windows since at least 2010!
                      http://www.youtube.com/watch?v=Cs9Ly...tailpage#t=67s

                      Comment


                      • #41
                        Originally posted by nerdopolis View Post
                        ONLY kill unresponsive apps?
                        The display server that would later be called Weston has supported moving frozen windows since at least 2010!
                        http://www.youtube.com/watch?v=Cs9Ly...tailpage#t=67s
                        EDIT: Before someone freaks out, The resume issue that appears in that video from 2010 WAS FIXED

                        Comment


                        • #42
                          Originally posted by nerdopolis View Post
                          ONLY kill unresponsive apps?
                          The display server that would later be called Weston has supported moving frozen windows since at least 2010!
                          http://www.youtube.com/watch?v=Cs9Ly...tailpage#t=67s
                          OMG now even moving windows is supposed to be a highly innovative feature or what? That video clearly shows: No minimizing of hanging windows and no moving hanging windows via CLD it's only possible via a special key combo.
                          Conclusion: Client-side decorations absolutely suck and any proponent is a retard!

                          Comment


                          • #43
                            Originally posted by Awesomeness View Post
                            OMG now even moving windows is supposed to be a highly innovative feature or what? That video clearly shows: No minimizing of hanging windows and no moving hanging windows via CLD it's only possible via a special key combo.
                            Conclusion: Client-side decorations absolutely suck and any proponent is a retard!
                            Well, back then in 2010, before many people saw Wayland in action as there was very few videos of it, there was fears here that with CSD, the windows won't be movable at all. Obviously that was not the case

                            As I mentioned in the last posts, the video is from late 2010. There was no minimize support because back then, (there wasn't even a SHELL yet in 2010, which there IS now, so there was no place for minimized apps to go)

                            Right now, the minimize protocol patches are currently not yet merged. (Yes there has to be a protocol for minimize so that applications can tell which of it's windows should get a task entry, (and which ones should not, such as menus and tooltips)). I have tested them, and although I can't minimize from the window right now, I can minimize a hung surface by clicking on its entry on the panel. This proves that the Wayland protocol does not hinder Weston from being flexible with hung windows.

                            Perhaps in the future a helper tooltip could be attached to windows that are hung to provide a minimize button.

                            As far as moving with having to move hung surfaces with the super key, there was no ping protocol, which was added sometime last year (which means that feature did not exist when that video was filmed). Now Weston detects hung windows, and currently makes the entire window dragable without having to use the super key command.

                            Point is, Wayland is not going to introduce MS Windows type usability problems that you see with hung Windows applications, just because Wayland currently relies on using client side decorations. The Wayland protocol is stable in the sense that there is going to be no more API breakerage, but desktop features are still under development, and still need work in some areas.

                            (in fact what I think is with the issue with Windows is that the windows are somehow managed by the client as well as the decorations, I think I read that somewhere. With Wayland there IS a window manager.)

                            There's even some talk on the IRC of introducing a protocol that tells applications to not draw a decoration, and determine which applications should be decorated for optional server side decorations.

                            Comment


                            • #44
                              Originally posted by Awesomeness View Post
                              I thought you were all so omniscient and yet do do not know that?
                              Check the Wayland video from the last Xorg conference, you genius! Michael recorded the entire conference and the videos were heavily featured and yet you missed that?
                              Idiot.

                              Wayland doesn't provide ANY ability to minimize apps yet. It's still being added.

                              The point is nothing will stop it from being able to allow frozen apps from being minimized. Once the functionality to do that for running apps is present, adding it for hung apps is TRIVIAL.

                              Learn to use basic problem solving skills.

                              Comment


                              • #45
                                While it will be supported, it will decidedly be a usability regression because of the need to poll the client, which is because Wayland's architecture.

                                Consider: I expect to be able to minimize* any window, any time, within 10ms**. No matter if the app is busy.

                                Under X, it works in all cases.

                                Under wayland, this would happen***: You click on minimize. Nothing happens. You wait 15 seconds. The app fades as unresponsive, and server controls are drawn. You have to re-click the new button.

                                This does three cardinal sins of user interface: it ignores your command, it makes you wait, and it makes you repeat your command. All usability regressions compared to the current state.


                                This is not possible to be worked around in the current design. Polling at 100Hz would waste your cpu unnecessarily, and even if it detected a hung app within 10ms, it would have to wait at least a second to avoid false positives. Kind of like Android touch screens have to wait after a tap to make sure it's not going to be a double tap (btw, I hate that wait as well. Terrible user design.).


                                * Optionally replace minimize here with mazimize, move, shade, and so on.
                                ** The generally agreed usability limit is 100ms. My demands are stricter, but they are not unrealistic - X with a suitable WM has been able to meet that for years.
                                *** Based on reading the ping protocol patches.

                                Comment

                                Working...
                                X