Thoughts about decoration information in the xdg_shell

Fri Nov 15 05:26:10 PST 2013

On Friday 15 November 2013 07:50:55 Jasper St. Pierre wrote:
> Ah, whoops, I read your email wrong. It sounds like you're also in favor of
> requiring CSD support from the client.
Yep, I'm fine with ensuring that CSD is the required fallback. As said: I don't 
want to force anybody to SSD :-)
> 
> 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
> environment?
I think that depends on whether the Nautilus developers want to have it 
integrate in other desktop shells than GNOME Shell. If you consider Nautilus 
to be a GNOME Shell only solution, then it certainly is not needed to adjust. 
If you on the other hand want to have Nautilus for as many users as possible I 
would recommend to adjust to the environment and remove the custom close 
button. After all it would be quite out of place in an environment where no 
other window has a close button like that. In an environment like Plasma 
Active it would certainly break the intended work flow to have such a button. 
Also for tiling concepts I would say it's better to hide. Also from experience 
I can tell that at least our users care about having windows behave the same 
way.

Cheers
Martin
> 
> 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
> >> 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/a
> > pplicationstest/work-gnome-continuous-x86_64-runtime/screenshot-nautilus.d
> > esktop.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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131115/7c0193df/attachment.pgp>