Thoughts about decoration information in the xdg_shell

[Jasper St. Pierre]

On Fri, Nov 15, 2013 at 8:07 AM, Alex Elsayed <eternaleye at gmail.com> wrote:

> Jasper St. Pierre wrote:
>
> > On Fri, Nov 15, 2013 at 6:17 AM, Martin Gräßlin
> > <mgraesslin at 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 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/c49d4061/attachment.html>