Thoughts about decoration information in the xdg_shell

[Alex Elsayed]

Thiago Macieira wrote:

> On segunda-feira, 18 de novembro de 2013 06:37:47, Martin Gräßlin wrote:
>> That sounds look a good solution to me!
> 
> Make it simpler: all clients MUST be able to draw decorations. That's what
> Wayland up until now requires anyway.

It's a given that they must be *able* to decorate themselves, however...

> A client MAY ask the compositor to draw decorations. If and only if the
> compositor replies that it will, the client is then not required to draw
> them. The only compositor likely to even understand this extension is
> kwin: it will reply "sure, I'll decorate" for any apps that request it. If
> necessary, the request can include a suggestion level on how strongly the
> client wants the compositor to do the decoration.

...there are cases where the decorations should not be shown at all. The 
netbook shell, for instance, handles decorations via a Plasma panel IIRC, 
and thus doesn't draw traditional decorations for fullscreen windows *at 
all*.

A client-initiated system like you describe CANNOT handle such a case.

> If the compositor does not reply to the extension, the application MUST
> decorate itself (according to whatever rules are prevalent, including no
> decorations for a tablet or mobile environment, etc.).
>
> If the application does not request it, the compositor MUST NOT decorate
> the windows -- it must assume the client is doing it properly. I'm
> guessing that most toolkits will not request it and will not provide a way
> for applications to do it either.

As stated above, this ignores the valid case of not wanting any decorations 
to be actually drawn *on* the windows, and the functionality instead being 
provided by another means.

I personally have both the top menubar *and* the decorations of fullscreen 
windows hidden, and the functionality appears in an autohiding plasma panel 
to conserve screen space. (dbusmenu/appmenu & kwin-button-applet)