On Fri, Nov 15, 2013 at 8:07 AM, Alex Elsayed <eternal...@gmail.com> wrote:
> Jasper St. Pierre wrote: > > > On Fri, Nov 15, 2013 at 6:17 AM, Martin Gräßlin > > <mgraess...@kde.org> wrote: > > > <snip, because gmane> > > > > 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 Martin's message: "It would require clients to support CSD" > 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. > What he's advocating is that, yes, everything must include _support_ for > CSD. But enabling it at _runtime_ should not be mandatory. > > > 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. > > And his proposal explicitly allows that. All it is is a communication > channel; the compositor politely requesting "I'd prefer [not] to draw the > decorations for you" and the application saying "I am [not] drawing my own > decorations." > > Without this, the two sides have no clean way to communicate that > information, and to do so requires ad-hoc, hackish attempts to support it > at > a layer that support does not belong in. With it, at least the left hand > and > right hand can tell what the other is doing. > > > 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.) > > As far as design changes between the devices, those are smaller than you > might think (especially with Qt Quick 2 and the work going on with that; > see > [1] and [2]) > > > I'm fine with a hint telling apps to not draw decorations, but I'd like > to > > mandate that CSD is supported by everything. > > As I noted, Martin's mail said the same thing. > > > [0] > http://build.gnome.org/ostree/buildmaster/results/tasks/applicationstest/applicationstest/work-gnome-continuous-x86_64-runtime/screenshot-nautilus.desktop.png > Link is a 404. > 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: http://build.gnome.org/ostree/buildmaster/builds/20131115.17/applicationstest/work-gnome-continuous-x86_64-runtime/screenshot-nautilus.desktop.png [1] > http://aseigo.blogspot.com/2012/10/one-code-base-multiple-form-factors.html > [2] > http://www.notmart.org/index.php/Software/Components_towards_a_new_plasma > > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Jasper
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel