<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 15, 2013 at 8:07 AM, Alex Elsayed <span dir="ltr"><<a href="mailto:eternaleye@gmail.com" target="_blank">eternaleye@gmail.com</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"><div class="im">Jasper St. Pierre wrote:<br>
<br>
> On Fri, Nov 15, 2013 at 6:17 AM, Martin Gräßlin<br>
> <<a href="mailto:mgraesslin@kde.org">mgraesslin@kde.org</a>> wrote:<br>
><br>
</div><snip, because gmane><br>
<div class="im">><br>
> I think the trap that I personally don't want to run into is the case<br>
> where we have a compositor that doesn't support SSD coupled to a client<br>
> that doesn't support CSD. Nobody can draw the decorations, and at this<br>
> point we've engineered the user into a corner.<br>
><br>
> For me, the debate about window decorations and Wayland is that we need<br>
> *something* to be mandated to be supported. GNOME wants that to be CSD,<br>
> and KDE wants that to be SSD.<br>
<br>
</div>From Martin's message: "It would require clients to support CSD"<br></blockquote><div><br></div><div>Yeah, I read his message wrong. I thought he was saying that requiring CSD was a bad idea, and his proposal was a negotiation mechanism where we support either.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
What he's advocating is that, yes, everything must include _support_ for<br>
CSD. But enabling it at _runtime_ should not be mandatory.<br>
<div class="im"><br>
> From the GNOME side, we're heavily using CSD features in our apps [0]<br>
> (such that we'd probably even ignore the Wayland hint to ignore CSD,<br>
> actually), and SSD code in mutter is a large pile of code I would not like<br>
> to maintain, as it's quite complicated, so it's natural for us to want to<br>
> encourage CSD.<br>
<br>
</div>And his proposal explicitly allows that. All it is is a communication<br>
channel; the compositor politely requesting "I'd prefer [not] to draw the<br>
decorations for you" and the application saying "I am [not] drawing my own<br>
decorations."<br>
<br>
Without this, the two sides have no clean way to communicate that<br>
information, and to do so requires ad-hoc, hackish attempts to support it at<br>
a layer that support does not belong in. With it, at least the left hand and<br>
right hand can tell what the other is doing.<br>
<div class="im"><br>
> I also think that CSD has technical advantages for complex server effects:<br>
> if we simply paint surfaces around the window, if we put the window into<br>
> e.g. Coverflow Alt-Tab, we won't see seams around the window. (And<br>
> personally, I'm of the opinion that any design changes you'd need to make<br>
> to apps to make them usable on a touch device vs. regular device stem far<br>
> beyond the window decorations they use in the end.)<br>
<br>
</div>As far as design changes between the devices, those are smaller than you<br>
might think (especially with Qt Quick 2 and the work going on with that; see<br>
[1] and [2])<br>
<div class="im"><br>
> I'm fine with a hint telling apps to not draw decorations, but I'd like to<br>
> mandate that CSD is supported by everything.<br>
<br>
</div>As I noted, Martin's mail said the same thing.<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>

Link is a 404.<br></blockquote><div><br></div><div>Yeah, this links to our live continuous integration server, and if it's re-running the applications test, the URL can point to an unfinished result. Here's a recent build that completed this morning:<br>
</div><div><br><a href="http://build.gnome.org/ostree/buildmaster/builds/20131115.17/applicationstest/work-gnome-continuous-x86_64-runtime/screenshot-nautilus.desktop.png">http://build.gnome.org/ostree/buildmaster/builds/20131115.17/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">
[1] <a href="http://aseigo.blogspot.com/2012/10/one-code-base-multiple-form-factors.html" target="_blank">http://aseigo.blogspot.com/2012/10/one-code-base-multiple-form-factors.html</a><br>
[2] <a href="http://www.notmart.org/index.php/Software/Components_towards_a_new_plasma" target="_blank">http://www.notmart.org/index.php/Software/Components_towards_a_new_plasma</a><br>
<div class=""><div class="h5"><br>
_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>  Jasper<br>
</div></div>