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 enum. > > 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. Jonas _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
