[PATCH] xdg-shell: add draw states for xdg_surface
gschwind at gnu-log.net
Tue May 31 10:01:38 UTC 2016
Just a reply to EWMH/MOTIF comments,
EWMH semantic is the path already started within xdg, as far as remember
v6 have toplevel, popup and tooltips surfaces, and will probably have
many more in the future.
That why we need a description of the issue we trying to solve. I can
assume that the issue is about toplevel window or not, thus should be a
flags list per surface role ?
Thinking about the proposal, and guessing the underlying issue, I
figured out that drawing request is the proper choice, even if it
introduce the trashed motif hint , and it is justified, because
compositor may want draw toplevel window in different manner. But at the
moment I see only one case that is for draw_without_shadow, but we can
easily drift to draw_tiled_mode, draw_glued_left, draw_glued_top,
draw_glued_right, draw_moving, draw_while_wobbling. In the case of drop
down menu: draw_span_left, draw_span_top, draw_without_shadow ? Once
again please define the issue.
I'm not against this proposal, but in current shape it does not comply
my requirement to include it as "a standard that any DE will have to
My opinion does not weight a lot anyway.
 Side note: funnily, still implemented by all X11 WM, because EWMH
does not allow clients to declare that they draw their own borders.
On 31/05/2016 11:24, Olivier Fourdan wrote:
> 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.
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
More information about the wayland-devel