Thoughts about decoration information in the xdg_shell
Jasper St. Pierre
jstpierre at mecheye.net
Fri Nov 15 04:50:55 PST 2013
Ah, whoops, I read your email wrong. It sounds like you're also in favor of
requiring CSD support from the client.
That said, I'm curious about cases like Nautilus under SSD. Should we hide
the close button, or do anything like that to make it adapt to an SSD
On Fri, Nov 15, 2013 at 7:14 AM, Jasper St. Pierre <jstpierre at mecheye.net>wrote:
> On Fri, Nov 15, 2013 at 6:17 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
>> shell has
>> 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
>> handles or
>> not. So that the SSD-supporting compositor doesn't add a decoration
>> around a
>> 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?
> I think the trap that I personally don't want to run into is the case
> where we have a compositor that doesn't support SSD coupled to a client
> that doesn't support CSD. Nobody can draw the decorations, and at this
> point we've engineered the user into a corner.
> For me, the debate about window decorations and Wayland is that we need
> *something* to be mandated to be supported. GNOME wants that to be CSD, and
> KDE wants that to be SSD.
> From the GNOME side, we're heavily using CSD features in our apps 
> (such that we'd probably even ignore the Wayland hint to ignore CSD,
> actually), and SSD code in mutter is a large pile of code I would not like
> to maintain, as it's quite complicated, so it's natural for us to want to
> encourage CSD.
> I also think that CSD has technical advantages for complex server effects:
> if we simply paint surfaces around the window, if we put the window into
> e.g. Coverflow Alt-Tab, we won't see seams around the window. (And
> personally, I'm of the opinion that any design changes you'd need to make
> to apps to make them usable on a touch device vs. regular device stem far
> beyond the window decorations they use in the end.)
> I'm fine with a hint telling apps to not draw decorations, but I'd like to
> mandate that CSD is supported by everything.
>> Martin Gräßlin
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wayland-devel