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. 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. > 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. > > This last comments look to overlap with some already existing feature > > within the protocol, I think about the input shape. > > Not sure how this has anything to do with input shapes. True, I really meant fat borders, as in weston-terminal for example, not input shapes. Cheers, Olivier _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
