Page 1 of 5 123 ... LastLast
Results 1 to 10 of 42

Thread: Client Side Decorations For Wayland

  1. #1
    Join Date
    Jan 2007
    Posts
    14,539

    Default 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. #2
    Join Date
    Jan 2009
    Posts
    1,615

    Default

    toooooooooo much drama




  3. #3
    Join Date
    Mar 2010
    Posts
    33

    Default

    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.

  4. #4
    Join Date
    Jun 2006
    Posts
    94

    Lightbulb 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:

  5. #5
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,033

    Default

    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...

  6. #6
    Join Date
    Sep 2008
    Location
    Seattle, WA, US
    Posts
    103

    Default unacceptable

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

  7. #7

    Thumbs down 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.

  8. #8
    Join Date
    Jul 2010
    Posts
    69

    Default

    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.

  9. #9
    Join Date
    Oct 2009
    Location
    .ca
    Posts
    402

    Default

    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.

  10. #10
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,128

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •