[PATCH RFC] xdg-shell: Add tiled states

Mike Blumenkrantz michael.blumenkrantz at gmail.com
Wed Jun 1 13:48:08 UTC 2016


Hi,

On Wed, Jun 1, 2016 at 5:19 AM Olivier Fourdan <ofourdan at redhat.com> wrote:

> When tiled, clients must obey the window geometry specified in the
> configure event and can choose to hide some of their decorations.
>
> Signed-off-by: Olivier Fourdan <ofourdan at redhat.com>
> ---
>  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 27
> +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
>
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> index ce57153..550a0e5 100644
> --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -343,6 +343,33 @@
>           active. Do not assume this means that the window actually has
>           keyboard or pointer focus.
>         </description>
> +      <entry name="tiled_on_top" value="5" summary="the surface is tiled
> on its top edge">
> +       <description summary="the surface is tiled on its top side">
> +         The top side of the surface is tiled, either to another surface
> +         or a monitor edge. The window geometry specified in the configure
> +         event must be obeyed by the client.
> +       </description>
> +      </entry>
> +      <entry name="tiled_on_bottom" value="6" summary="the surface is
> tiled on its bottom edge">
> +       <description summary="the surface is tiled on its bottom side">
> +         The bottom side of the surface is tiled, either to another
> surface
> +         or a monitor edge. The window geometry specified in the configure
> +         event must be obeyed by the client.
> +       </description>
> +      </entry>
> +      <entry name="tiled_on_left" value="7" summary="the surface is tiled
> on its left edge">
> +       <description summary="the surface is tiled on its left side">
> +         The left side of the surface is tiled, either to another surface
> +         or a monitor edge. The window geometry specified in the configure
> +         event must be obeyed by the client.
> +       </description>
> +      </entry>
> +      <entry name="tiled_on_right" value="8" summary="the surface is
> tiled on its right edge">
> +       <description summary="the surface is tiled on its right side">
> +         TThe right side of the surface is tiled, either to another
> surface
> +         or a monitor edge. The window geometry specified in the configure
> +         event must be obeyed by the client.
> +       </description>
>        </entry>
>      </enum>
>
> --
> 2.7.4
>
>
>
I've read the ticket linked in the other mail, but your use of "tiled" here
is confusing to me since you (and the ticket) appear to be conflating two
separate-but-unrelated meanings.  "Tiled" is a type of window layout policy
which organizes windows into a tiled grid formation; this is in opposition
to "stacking".

The ticket you linked seems to be primarily about positioning windows to
take up 50% of screen geometry, (e.g., left half of screen, top half of
screen, ...). This seems a lot more like a maximize state to me since it's
based on screen geometry. In X11 there's NETWM hints for
vertical/horizontal maximize: EFL uses these to handle partial
maximizations, and in Wayland we simply use the normal MAXIMIZE window
state since directionality is irrelevant. I think MAXIMIZE fully covers
this case and there is no need for any further protocol to inform the
client.

In the case of the real "tiled" state, (i.e., a tiling layout policy), I
think this is something which should be a single draw state. There's no
need to inform a client about its surface's relative position (e.g., any of
your proposed directional tiled values) since the result is the same in
every case--the client must obey configured geometry.

The difference from the MAXIMIZE state here is mostly conceptual: MAXIMIZE
indicates to a client that a surface is taking up the entire screen's
geometry on at least one axis and thus it may choose to draw UI elements
differently (e.g., showing/hiding extra toolbars along the larger axis). A
TILED state simply informs the client that it must obey sizing policies and
draw rectangular borders. A MAXIMIZED surface cannot be tiled (since it's
implicitly "tiled" by being maximized), but a tiled surface can toggle
MAXIMIZE.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160601/5e8c4323/attachment.html>


More information about the wayland-devel mailing list