Please Don't Use Cleint Side Window Decorations

[Dana Jansens]

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.

> btw. Has anyone ever asked the developers of the major desktop environments,
> windows managers and toolkits what they want?

For example: http://live.gnome.org/GTK+/ClientSideDecorations

Cheers,
Dana


ps Being a WM developer (Openbox) for 7 years, I am at least one more
voice on the issue with some awareness of the issues.

-- 
http://openbox.org