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

Mike Blumenkrantz michael.blumenkrantz at gmail.com
Tue May 31 15:40:41 UTC 2016

After a long weekend of not reading mails, I've read some mails; I'll try
to make comments to everything in this reply.

On Tue, May 31, 2016 at 7:38 AM Olivier Fourdan <ofourdan at redhat.com> wrote:

> Hey
> ----- Original Message -----
> > On Tue, May 31, 2016 at 05:24:35AM -0400, Olivier Fourdan wrote:
> > > [...]
> > > 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.
> Just a quick note before my main power source goes down here, my comment
> are not about tiling, as stated before, I just tool tiling as an example of
> where we eanted to have a value per edge.
> FWIW, I don't think tiling is a "draw state", I reckon it's a plain state
> just like "maximized" or "active". But tiling is worth its own thread :)
> Cheers,
> Olviier
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

* Range allocations were added only because it was created in a similar way
to the configure state enum, which has such allocations. I don't care much
about them and I had no plans to use them at this time.

* This patch is solely about implementing the basic idea of "draw
states"--a method for negotiating and controlling the manner in which the
client draws its windows. I don't see a need to "define the issue" further
than "this is a new display server protocol, let's ensure there's a
standard way to negotiate/control drawing between the server and clients".
This is clearly different from window states due to 1) negotiation, and 2)
specifically related to drawing only, not behavior.
** The initial value of "no shadow" exists because it's a useful thing to
have in some cases (e.g., flat ui theme in compositor+toolkit, compositor
wants to draw special shadow effects, ...) and is not
controversial--moreover, it's trivial to implement compared to other
potential states.

The concept of draw states is easy to envision extensions for when provided
with this base example, and these extensions can be discussed at a later
time and in a separate thread if everyone can agree on the premise. A tiled
state is certainly something worthwhile to consider at that time and place.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160531/e7d4896b/attachment-0001.html>

More information about the wayland-devel mailing list