Thoughts about decoration information in the xdg_shell
jason at jlekstrand.net
Sat Nov 16 09:32:50 PST 2013
On Nov 15, 2013 5:27 AM, "Martin Gräßlin" <mgraesslin at kde.org> wrote:
> Hi all,
> this is a reply to the topic of whether to have information about
> in the xdg_shell at all (see ). Sorry that I don't reply to the right
> message, had not been subscribed to the list.
> I want to outline why we in the KDE Plasma team would prefer to have the
> possibility to tell clients whether to draw decorations or not. In Plasma
> have multiple shells and will be able to switch at runtime. From the
> manager perspective the main difference is currently the handling of
> decorations. Our touch oriented shell doesn't have decorated windows, our
> netbook shell only has decorated windows for dialogs and our desktop
> a typical window decorated style, but not enforcing SSD (there are valid
> cases like yakuake).
> This gives us quite some flexibility to adjust at runtime (add keyboard to
> tablet to get a desktop). An application doesn't need to know what the
> currently looks like. The shell takes care of handling all of that.
> If we don't have information about whether the window should be decorated
> not in the xdg_shell we would need to adjust all applications to know
> our various shells. Otherwise a consistent user experience would not be
> possible. Also it removes all possibilities to take this further in the
> Now I don't want to force SSD to anybody nor do I want to be forced to
> Therefore I want to have a very simple spec, which allows the compositor
> tell the clients whether they are expected to render decos themselves
> CSD, e.g. GNOME Shell), whether the compositor doesn't care, but prefer
> to not render themselves (e.g. Plasma Desktop case) or whether the
> wants the client to not render any handles at all (enforce SSD, Plasma
> In addition the client should tell the compositor whether it draws
> not. So that the SSD-supporting compositor doesn't add a decoration
> CSD client.
> I think this would be a good solution. It would require clients to support
> CSD, but also to not render them in shells, which prefer to not have them.
> Also it doesn't force CSD applications to support it. They could just
> that they do CSD no matter what.
> Opinions? Would that be acceptable for everybody?
> Martin Gräßlin
I think I know how we can handle all of the use-cases described above and
still deal with Jasper's concerns about no one decorating at all. My
suggestion would be to have a pair of flags that get sent with the
configure event or in their own event that tells the client how to
decorate. (I would vote for their own event to avoid making configure even
more monolithic, but that's immaterial.)
The first flag would be the compositor's preference as to whether the
client should decorate or not. If 1, the server prefers that the client
draws decorations; if 0, the server prefers to handle decorating itself.
The second flag would specify whether the first flag is strict or just a
suggestion. If 1, the client must do as specified in the first flag; if 0,
it is only a suggestion and the client may do otherwise. For the use-cases
listed in this thread, this would work out as follows:
1) GNOME shell would always set 11, CSD-strict. Any client that does not
draw decorations is considered a bad client and gets what it gets.
2) Fullscreen surfaces will always recieve 01, SSD-strict.
3) KWin's desktop shell would set 00, SSD-suggested. It would prefer that
clients let KWin do the decorating but if a client really wants its own
decorations, it can.
4) KWin's tablet shell would set 01, SSD-strict to tell clients that they
must not decorate. Then it is free to decorate them/tile them at will.
5) KWin's netbook shell would set 00 for dialogues and 01 for main windows.
Somewhere in here we would also need an event to let the client tell the
server whether it decided to decorate or not. There's also a race in here
that we need to solve, but I think we can handle that.
There's my thoughts. Jasper, Martin, and Rafael. Does this look good to
you? I think it solves all the cases. I've got a few more ideas that
extend what's given here but, to avoid added bikeshedding, I'm leaving them
out for now.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wayland-devel