[PATCH] xdg-shell: add draw states for xdg_surface

Jonas Ã…dahl jadahl at gmail.com
Tue May 31 11:26:55 UTC 2016

On Tue, May 31, 2016 at 05:24:35AM -0400, Olivier Fourdan wrote:
> Hey
> Just to make it clear, as a foreword to my comments inline below, I am not against the patch, far from it, I just wanted to make sure we considered edge values instead of only "no shadow", and we also considered other draw states.
> If we considered and dismissed them, fine.

They are not "actively" considered in this patch, but as I mentioned
earlier, I think tiling states can later be added to the window state

> For reference, this reminds me of the windows' semantics in EWMH. Before EWMH, apps would use Motif MWM hints to specify if they wanted to have borders, title, buttons, etc. With EWMH, apps would rather advertise a type of window (dialog, menu, etc.), and the WM would decide how to decorate them, so it would be a lot more consistent between apps. I still prefer the EWMH approach to the MWM hints ^_~
> Back to the topic...
> ----- Original Message -----
> > On Tue, May 31, 2016 at 10:31:28AM +0200, Benoit Gschwind wrote:
> > > Hello Jonas, Mike and Olivier,
> > > 
> > > [...]
> > > > I see nothing wrong with it in a separate (optional) protocol for
> > > > experimenting, but as soon as we have clients and compositors using
> > > > private values out in the field, it might become harder to put things
> > > > back into the agreed standard set.
> > 
> > I don't see why. We either have two integer values meaning the same
> > thing (the "upstreamed" number, and the private), or we have an
> > upstreamed integer part of the xdg_ and a private integer part of a
> > separate protocol.
> > 
> > The "upstreaming" procedure would be identical anyhow: writing a patch
> > adding the new entry to the enum.
> No, for private ranges, no patch is needed as the values are private and do not need to be documented in the standard. 
> I think it's the sore point, having undocumented, private values in a standard.

As said in the other mail, personally I'd be fine with dropping range
allocation and requiring toolkits etc to add their own enums and
configure events.

> > Either way, semantically, the result will be identical. Personally I
> > don't care much whether per DE state enum entry allocations are to be
> > the current way or or in an extensions really with its own configure
> > event. Removing alloctions it from xdg_ would only an inconvenience to
> > do the exact same thing.
> > 
> > Just to repeat, the purpose of range allocations is to DE:s to make use
> > of the already present configure/ack_configure and now set_available_...
> > parts, but with their own private (not part of xdg_) integers, without
> > the issues of introducing any incompatibilities with other toolkits and
> > compositors. None of these private entries would ever be added or
> > referenced in xdg_shell.
> Precisely, the point is that it defeats the purpose of a "standard" which is, by definition, aimed to be shared between different implementations.
> > > At the moment, You proposal just address the issue of the shadow, thus a
> > > simple set_no_shadow event should be enough ?
> > 
> > The reason for having a "draw state" besides "window state" (the state
> > we already have) is so that we have one state that is properly
> > negotiated. The window state is not negotiated; a compositor will just
> > add states it thinks the client should know about, but doesn't care much
> > whether the client changed its drawing in any way.
> > 
> > For draw states, the purpose of adding an entry is for when the
> > compositor actually cares. Shadows is one such thing, because as far as
> > I know for example KDE intends to draw its own server side shadows, and
> > could use a "no shadow" draw state to figure out whether it is possible.
> OMG SSD! :) In this case you'd need "no border" and "no title bar" as well.

I imagine such entries could be added to the draw state enum indeed. I
also will assume such entries will stay unused by for example the
default weston desktop shell and mutter, but thats another story.


More information about the wayland-devel mailing list