<div dir="ltr"><div class="gmail_extra">Ah, whoops, I read your email wrong. It sounds like you're also in favor of requiring CSD support from the client.<br><br></div><div class="gmail_extra">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?<br>
</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 15, 2013 at 7:14 AM, Jasper St. Pierre <span dir="ltr"><<a href="mailto:jstpierre@mecheye.net" target="_blank">jstpierre@mecheye.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On Fri, Nov 15, 2013 at 6:17 AM, Martin Grlin <span dir="ltr"><<a href="mailto:mgraesslin@kde.org" target="_blank">mgraesslin@kde.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
this is a reply to the topic of whether to have information about decorations<br>
in the xdg_shell at all (see [1]). Sorry that I don't reply to the right<br>
message, had not been subscribed to the list.<br>
<br>
I want to outline why we in the KDE Plasma team would prefer to have the<br>
possibility to tell clients whether to draw decorations or not. In Plasma we<br>
have multiple shells and will be able to switch at runtime. From the window<br>
manager perspective the main difference is currently the handling of window<br>
decorations. Our touch oriented shell doesn't have decorated windows, our<br>
netbook shell only has decorated windows for dialogs and our desktop shell has<br>
a typical window decorated style, but not enforcing SSD (there are valid use<br>
cases like yakuake).<br>
<br>
This gives us quite some flexibility to adjust at runtime (add keyboard to<br>
tablet to get a desktop). An application doesn't need to know what the shell<br>
currently looks like. The shell takes care of handling all of that.<br>
<br>
If we don't have information about whether the window should be decorated or<br>
not in the xdg_shell we would need to adjust all applications to know about<br>
our various shells. Otherwise a consistent user experience would not be<br>
possible. Also it removes all possibilities to take this further in the<br>
future.<br>
<br>
Now I don't want to force SSD to anybody nor do I want to be forced to CSD.<br>
Therefore I want to have a very simple spec, which allows the compositor to<br>
tell the clients whether they are expected to render decos themselves (enforce<br>
CSD, e.g. GNOME Shell), whether the compositor doesn't care, but prefer them<br>
to not render themselves (e.g. Plasma Desktop case) or whether the compositor<br>
wants the client to not render any handles at all (enforce SSD, Plasma Active<br>
case).<br>
<br>
In addition the client should tell the compositor whether it draws handles or<br>
not. So that the SSD-supporting compositor doesn't add a decoration around a<br>
CSD client.<br>
<br>
I think this would be a good solution. It would require clients to support<br>
CSD, but also to not render them in shells, which prefer to not have them.<br>
Also it doesn't force CSD applications to support it. They could just announce<br>
that they do CSD no matter what.<br>
<br>
Opinions? Would that be acceptable for everybody?<br></blockquote><div><br></div></div></div><div>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.<br>

<br>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.<br><br>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.<br>

</div><div><br>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.)<br>

<br>I'm fine with a hint telling apps to not draw decorations, but I'd like to mandate that CSD is supported by everything.<br><br>[0] <a href="http://build.gnome.org/ostree/buildmaster/results/tasks/applicationstest/applicationstest/work-gnome-continuous-x86_64-runtime/screenshot-nautilus.desktop.png" target="_blank">http://build.gnome.org/ostree/buildmaster/results/tasks/applicationstest/applicationstest/work-gnome-continuous-x86_64-runtime/screenshot-nautilus.desktop.png</a><br>

<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
Cheers<br>
Martin Grlin<br>
<br>
[1] <a href="http://lists.freedesktop.org/archives/wayland-devel/2013-November/011980.html" target="_blank">http://lists.freedesktop.org/archives/wayland-devel/2013-November/011980.html</a><br>
<br></div>_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
<br></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br> Jasper<br>
</font></span></div></div>
</blockquote></div><br><br clear="all"><br>-- <br> Jasper<br>
</div></div>