Announcement

Collapse
No announcement yet.

Client Side Decorations For Wayland

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

  • Client Side Decorations For Wayland

    Phoronix: Client Side Decorations For Wayland

    Besides OpenWF support in Wayland being talked about and on the roadmap, another item that's been hotly discussed the past couple of days is about client side decoration support for the Wayland Display Server...

    http://www.phoronix.com/vr.php?view=OTQxMA

  • #2
    toooooooooo much drama



    Comment


    • #3
      How about allowing the compositor to request the application not to render decorations. Then the author of the compositor can decide, if he/she wants to allow the application to control its window or not.

      Comment


      • #4
        KDE KWin and client-side window decorations

        KWin developer has also writen quite a lot about clent-side decorations and also came to the conclusion that it brings more bad than good:

        Comment


        • #5
          Kristian's point w/ unresponsive apps still relied on the app cooperating before the hang, having told where the borders and close button are. But if the compositor has no way to kill a client without cooperation, the clients can just not tell where their close button is and become invincible...

          Comment


          • #6
            unacceptable

            client side decorations are unacceptable. I will not use a system with such idiocy

            Comment


            • #7
              CSD is fundamentally broken

              I am at a loss. How can the people making the decisions be so dismissive about the serious fundamental problems of CSD?

              It all boils down to the fact that CSD is essentially nothing but a huge usability and security risk introduced for minimal gains.

              Unless WM and decoration policy is within the server, misbehaving applications, not to mention outright malicious ones, can do quite much whatever they please and the user may have very limited and crude tools to try and contain them.

              Someone mentioned that the problems would go away if the application defined areas within the window which the server monitors, expecting certain actions to take place and forcibly performing the associated actions, such as closing the application, if necessary. This requires both cooperation and defining these areas correctly. This means there is no guarantee of good behavior. With such a design, even with a reasonably well-behaved application, it will be difficult to properly handle situations like the "Do you want to save your changes?" dialog after clicking the close button. If the user spends any considerable time reading the dialog, they will be presented with a "Force close" dialog, which they might accidentally respond to in the affirmative, losing their work.

              If CSD is insisted upon, at least the following extension to the abovementioned policy is a must to avoid the worst of problems, albeit not all: the server and the client negotiate locations, sizes and shapes for various window controls, such as the close button. The client is free to draw those areas in any way it sees fit, just like any other area. Any client that fails to negotiate reasonable values for these will be rejected or default window movement policies, locations, shapes and sizes will be applied and the corresponding buttons are forcibly drawn (preferably in the ugliest and most disturbing way possible). The handling of clicks within the areas negotiated is done by the server, with optional pre-action and post-action callbacks supplied by the client.

              Comment


              • #8
                Client-side decorations will create lots of mess. It should be leaved allone to window managers. And anyway toolkits can experiment with some decoration-less windows, and paint decorations by itself. But client-side decorations will create lots of incoherence, security problems, freezing issues, and other possible problems.

                Comment


                • #9
                  Maybe I'm getting old but already now I hate it if clients come with their own or no decorations. It's only done for the sake of being 'different' or to dictate/limit usage patterns and we have yet to see a real useful application for it.
                  And as a user I don't care if CSD makes for prettier code in the compositor.

                  Comment


                  • #10
                    As a resident of these forums, I hope the Wayland developers go forward with client-side decorations, just out of spite towards people who preconceived ideas and terrible lack of knowledge.

                    Security risk my ass.

                    Comment


                    • #11
                      Originally posted by not.sure View Post
                      Maybe I'm getting old but already now I hate it if clients come with their own or no decorations. It's only done for the sake of being 'different' or to dictate/limit usage patterns and we have yet to see a real useful application for it.
                      And as a user I don't care if CSD makes for prettier code in the compositor.
                      Ok, on a more serious note, this has nothing to do with CSD or SSD. Clients can draw whatever they wish, just like Google Chrome does on Linux right now. CSD will change nothing in this regard.

                      Comment


                      • #12
                        Better safe than sorry

                        I may not know all the ins and outs of the matter at hand (I mean despite carefully reading the whole Wayland CSD thread and understanding the arguments from both sides), but as far as I'm concerned, being unable to enforce proper behavior completely defeats the whole purpose of things like operating/window system (pardon my ignorance, but I'm simply thinking of a window system/compositor as a sort of "operating system for application viewports").

                        And don't get me started with the old "then just don't install/run it" argument, because how am I supposed to know which crap to avoid until I execute the damn thing and it completely screws up my desktop?

                        Comment


                        • #13
                          Originally posted by 89c51 View Post
                          toooooooooo much drama
                          Well we need something to distract us from our jig dancing on Osama effigies.

                          Plus it is always fun to speculate on a display system that will go nowhere as long as it is unsupported by nVidia and AMD.

                          Comment


                          • #14
                            It's easy enough to deal with unresponsive apps. In fact, Kristian's solution is more work than it's worth. Just do what Windows does and create a frame on the fly for unresponsive apps which is owned by the window manager (in this case, Wayland).

                            Comment


                            • #15
                              Originally posted by siride View Post
                              It's easy enough to deal with unresponsive apps. In fact, Kristian's solution is more work than it's worth. Just do what Windows does and create a frame on the fly for unresponsive apps which is owned by the window manager (in this case, Wayland).
                              Exactly! This is one of the few things that Windows gets right, I think. When an app is unresponsive, it makes a new window containing a faded-out image of the last frame successfully rendered by the app, with default window decorations, and gives you the option of closing it out. Granted, I don't like the way that it "checks for a solution" from Microsoft, but the core design at a compositor level is sound.

                              If this kind of behavior can be implement while preserving the flexibility of CSD, then go ahead and do it. This is essentially "CSD unless the app does something really dumb, then SSD steps in and saves the user from a kill -9". Perfect.

                              Comment

                              Working...
                              X