[PATCH RFC] Add tiled states per edge

[Quentin Glidic]

Hi all,

I will try to summarize all the discussion about tiling that this thread 
has generated, and if all goes fine, we will see that we mostly all 
agree with each other.

First, definitions:

Stacking/Floating: this is the “classic” way of managing windows, 
directly inherited from the desktop metaphor. Windows goes “on top of 
each other”, so you cannot see the ones below without moving the ones on 
the front.

Tiling: a rather well-known paradigm, where windows do not hide each 
other. Most of the time, it’s coupled with the idea that no screen space 
should be wasted, but it is not mandatory (see e.g. i3-gaps or even Sway 
IIRC).

Maximize: this concept is mostly tied to stacking/floating, as it is 
meant to make one window cover all others (by covering the whole screen, 
except DE UI). This state is temporary, as focusing another window will 
break it.
It breaks the *feature* (covering all other windows), not the window 
state; but a WM/compositor could revert that state.


Now, let’s see who is using which terms.

 From what Mike said, E(nlightenment) supports both stacking/floating 
and tiling.
In GNOME(-Shell), there is “partial tiling”. With a (few) keystroke(s) 
you can put two windows side-by-side on one screen.
In i3, Sway and any tiling window manager/compositor, tiling is there, 
with usually basic support for stacking/floating, mostly for dialogs or 
to workaround bad behaving clients (Java, Steam).
I am not familiar enough with KDE so I’ll skip it, sorry. :-)

As we can see, GNOME is the outstanding one.
GNOME is using stacking/floating management, no “true” tiling here. The 
“partial tiling” feature is actually, as Mike said, “partial maximize”: 
a temporary “covering part of my screen” feature.


Another relevant point: clients tend to use shadows as resize handlers 
nowadays.

There is a need to tell clients there are tiled (as in “real” tiling), 
but is this the same need as “partial tiling”?
It seems obvious to me that the non-GNOME answer is “no”.


Now, here is my proposal:

A single "tiled" state, for “real” tiling. The client must obey the 
geometry and drop the decorations and shadows. Resizing is initiated by 
the compositor only (either to tile or by explicit user resize action).

GNOME will use the "maximized" state, because it really is that, but 
with a variation: we add some "you-can-draw-stuff-on-<edge>" draw 
states, only meaningful in the "maximized" state.
This means the normal non-maximized draw state is “you can draw 
shadows/borders”, but once maximized, you have to negotiate to still 
render shadows/borders on the potential non-maximized edges.

How are you feeling about it?


Now, one last thing to think about:

As we saw, maximize makes little sense in tiling, so clients should hide 
their maximize/unmaximize button. But Benoit thinks it can be of use. 
The minimize and close buttons are not actually that different.

To me, these should be compositor-specific actions, rather than 
something clients are aware of. IMO, tiling is also “the compositor 
knows better”, and thus the client should not initiate actions.


I hope it makes things a little clearer, and hopefully lead us to a 
final decision.

Cheers,

-- 

Quentin “Sardem FF7” Glidic