Thoughts about decoration information in the xdg_shell

[Jasper St. Pierre]

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
> decorations
> in the xdg_shell at all (see [1]). 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
> we
> have multiple shells and will be able to switch at runtime. From the window
> manager perspective the main difference is currently the handling of window
> 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
> use
> 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
> shell
> 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
> or
> not in the xdg_shell we would need to adjust all applications to know about
> our various shells. Otherwise a consistent user experience would not be
> possible. Also it removes all possibilities to take this further in the
> future.
>
> Now I don't want to force SSD to anybody nor do I want to be forced to CSD.
> Therefore I want to have a very simple spec, which allows the compositor to
> tell the clients whether they are expected to render decos themselves
> (enforce
> CSD, e.g. GNOME Shell), whether the compositor doesn't care, but prefer
> them
> to not render themselves (e.g. Plasma Desktop case) or whether the
> compositor
> wants the client to not render any handles at all (enforce SSD, Plasma
> Active
> case).
>
> 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
> announce
> 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 [0] (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.

[0]
http://build.gnome.org/ostree/buildmaster/results/tasks/applicationstest/applicationstest/work-gnome-continuous-x86_64-runtime/screenshot-nautilus.desktop.png

Cheers
> Martin Gräßlin
>
> [1]
> http://lists.freedesktop.org/archives/wayland-devel/2013-November/011980.html
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>


-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131115/67ed401f/attachment-0001.html>