Please Don't Use Cleint Side Window Decorations

[Alexandre Mazari]

The points made by krh four years ago [0] still hold true and are
still the most convincing arguments for CSD I've read.

[0] http://people.freedesktop.org/~krh/client-side-decorations.txt for 4 years


2010/11/16 Kristian Høgsberg <krh at bitplanet.net>:
> On Tue, Nov 16, 2010 at 11:27 AM, Dana Jansens <dana at orodu.net> wrote:
>> On Tue, Nov 16, 2010 at 3:55 AM, Fabian Henze <flyser42 at gmx.de> wrote:
>>> Hello,
>>>
>>> On Tuesday, 16 Nov 2010, 01:22:42-UTC, Dana Jansens wrote:
>>>> I think it is important to point out that this conversation has been
>>>> predicated entirely on the idea that window decorations and window
>>>> managers are the same thing.
>>>>
>>>> Window management is - at its core - a filter for focus and window
>>>> manipulation requests.  It does not require that the WM also draw the
>>>> window decorations.  A window can initiate an move/resize just as well
>>>> as the WM itself can, via a request to the WM.
>>>
>>> Could you elaborate, why this makes such a big difference? While I am aware of
>>> this distinction, I don't think it changes the situation at all.
>>
>> Because the discussion was talking about where to put decorations, but
>> the advantages/disadvantages were talking about where to put control
>> of window placement/focus control.  If talking about where to put
>> decorations, it should only be talking about advantages/disadvantages
>> of that decision, and the WM logic is independent.
>>
>>>
>>>> I think it would be a
>>>> big step to make this separation clear from the start, and have window
>>>> decorations separate from the WM functionality, wherever they end up.
>>>
>>> The thing I don't understand about this whole discussion is: How would this be
>>> a big step? Why would you want to put this kind of logic in the client?
>>>
>>> I see numerous issues (please correct me if they are actually non-issues):
>>> 1. advanced WM features won't work, like: disallow fullscreen for certain
>>> windows, always maximize a certain window, resize and move using user-defined
>>> hotkeys, snap to window borders.
>>> 2. I just don't believe that GTK, Qt and all the minor toolkits will agree on
>>> standards for window decoration and behaviour. That would make the linux
>>> desktop even more inconsistent than it is now.
>>> 3. Freezing clients, remote clients with a hung connection, stopped clients
>>> (CTRL-Z) may cause unmovable windows.
>>> 4. code and bug (!) duplication in every toolkit.
>>> 5. Malware, adware or scareware easily have way too much control about the
>>> graphical environment.
>>>
>>> To sum it up: I am concerned, that most features that make X11 window managers
>>> absolutely rock compared to Windows or OSX will be gone.
>>
>> I agree that WMs are great and have been working on one for years
>> because of this.
>>
>> But I also believe separating functionality and presentation would be
>> a good step, and an improvement over the current model in X.
>> Separation along these boundaries is a pretty common pattern in
>> software design.  I'm not saying that applications should be
>> responsible for behaviour, though.  As you stated, and others have
>> also pointed out shortcomings of that.
>>
>> Instead, I would like to see a standard interface in the compositor
>> for a WM component that could act on focus and window change requests.
>>  But if decorations are drawn by the compositor, it should provide a
>> separate interface for decorations.  This way you can choose your
>> decoration style independent of your WM behaviour.
>>
>> Of your above examples, the only one a toolkit could not cleanly
>> handle is the ^Z case.  And it would still be possible to kill the
>> process in this case, so I don't think it is something that should be
>> a deal breaker either way.
>>
>>>>
>>>> Personally, I think toolkits could do a better job of rendering
>>>> decorations than the compositor could.
>>>
>>> Why? and in which way?
>>
>> A lot of work goes into making themes match with the toolkit, and each
>> WM has to do an equal amount of effort to do this.  Or blending
>> decorations and window contents together.  GTK and Qt have both done a
>> pretty good job of providing skinnable/malleable interfaces, and I
>> would expect that continue with decorations.
>>
>> Also, if you'd like to allow windows to provide non-rectangular
>> interfaces - such as many OSX apps can do - then the toolkit would be
>> a much better place to worry about decorations, as it will understand
>> the context of the shapes in its window, while an external decorator
>> will not.  I would like to leave the paradigm of everything is a
>> rectangle far behind.
>>
>>>> Secondly, there seems to be a belief that people would write wayland
>>>> applications without any toolkit - that wayland would be a toolkit in
>>>> essence, like Xlib is.  Also, similar to the demo apps that are
>>>> currently given.  But from what I see of the project, it would be
>>>> expected that applications would be developed using a reasonable
>>>> toolkit such as Qt or GTK, and thus those toolkits can provide all the
>>>> functionality clients are concerned about - such as threading for
>>>> window interaction and so on.  I don't see any reason to try push any
>>>> of that onto the compositor/WM.
>>>
>>> While I generally agree, I would like to point out that some applications
>>> might not require a toolkit. The most prominent example would be 3d games, but
>>> I think there are also other special purpose applications, that might not want
>>> to use a toolkit (like proprietary ports of windows software).
>>
>> A toolkit provides a lot more than just widgets. Everything needs a
>> toolkit of some sort, or else they are writing their own toolkit.  X
>> apps that use Xlib are also using a toolkit, abeit a simple and very
>> obsolete one.  Just dealing with things like window creation, window
>> focus, interaction with the WM etc are functionalities of a toolkit.
>
> Dana, you're basically making all the points I was going to make.
> There's a difference between client side window management and client
> side window decorations.  Wayland relies on clients drawing their own
> decorations, but the window management is done by the compositor.  The
> clients are responsible for detecting when an input device tries to
> move, resize or lower the client surface, by handling clicks and drags
> in the title bar or window frame.  Once a client has decided that an
> input device has clicked its title bar, the client tells the
> compositor "please move me".  The compositor will then move the window
> around, snapping to other window and screen edges as it goes.  The
> compositor can decide to move the window without the client getting
> involved, similar to how metacity (for example) can move a window if
> you alt+leftclick anywhere in the window, in the demo compositor this
> is bound to super+leftclick.
>
> I think some people have taken "client side decorations" to mean all
> bad things that Windows do, but it's really just about letting
> applications draw their own titlebars and borders.  There will still
> be a central process that can move windows around, raise or lower
> them, or force-close them whether or not the clients are responsive.
> Letting clients draw their own decorations has a lot of benefits -
> better performance, less work when compositing, more flexibility for
> theming and better visuals for transformed windows.
>
> Kristian
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



-- 
"If you open your mind too much, you brain will fall out"
Tim Minchin