[PATCH RFC] xdg-shell: Add tiled states

[Olivier Fourdan]

Hi Mike,

----- Original Message -----
> 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".

Sure, I appreciate that.
 
> 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.

This is the current use of "tiling" in gnome-shell and gtk+, but we should not limit tiling to a single (very limited) implementation.

> I think MAXIMIZE fully covers
> this case and there is no need for any further protocol to inform the
> client.

I reckon using partial maximization from EWMH to achieve basic tiling in gnome-shell/gtk+ was a hack, it leads to all sort of workarounds in gtk+:

https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkdisplay-x11.c#n244

And it doesn't even take into account horizontal tiling, https://bugzilla.gnome.org/show_bug.cgi?id=742525

I'd rather not mix up maximization and tiling again, given the chance...

> 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 client may chose to draw the border on the surface edged tiled differently, to achieve seamless borders between tiled windows for example, while keeping the other edges (not tiled) unchanged, that was the idea behind the use of the edge values.
 
> 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.

I see where you're coming from, if we consider a single "tiled" state then it's similar in essence to the maximized state with a different geometry, so we could get away with a "tiled" draw state instead that clients would use to distinguish from the real "maximize" state when drawing their decorations (including the "maximize" button in the title bar which can differ when maximized or not).

Granted, I am not a tiling window manager aficionado myself, so it would be great if those who design tiling window managers could chime in as well and express their needs wrt. tiling.

Cheers,
Olivier