Please Don't Use Cleint Side Window Decorations

[Kristian Høgsberg]

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