[PATCH RFC] Add tiled states per edge

[Jonas Ådahl]

On Fri, Jul 08, 2016 at 11:58:13AM +0200, Quentin Glidic wrote:
> 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.

The tiling code is being worked on to add more tiling configurations.
Don't confuse it with maximize, thats something else.

> 
> 
> 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.

No. Lets not bring draw states (I'm more and more thinknig its the wrong
name, its not related to the window states, if you think you want to add
any entry to the draw states enum, the answer is quite likely "no").

Also no, using maximized is a work-around for the lack of any "tiled"
window state. The GNOME tiling state is, as I said, maximized.

> 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.

There is no point in negotiating anything here.

> 
> How are you feeling about it?

I see no reason for not just going with the initial approach by having
four tiling states. sway and other tiling compositors would always set
all sides as tiled. Half-screen tiled GNOME would set the edges it
considers "tiled" as tiled, and GTK+ can in both cases draw shadow etc
where it wants to.

sway would never get any shadow, and would always deal with resizing of
all edges, as long as it keeps the windows tiled on all edges; it'll
work perfectly fine.  gnome-shell is allowed to have its half tiled
state if it wants, or add 1/4 tiled or whatever. GTK+ would in both
cases know what to do, and both gnome-shell and sway get what they want.

> 
> 
> 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.

Maybe so. Lets not drag this into this discussion though (telling
clients whether to draw the maximize icon or not).

> 
> 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.

Indeed. We don't have any "tile me" request. We need a maximize request
because that is a very common thing to have. But lets not get into that
now.

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

Sure. As I said, going with the initial approach with four states allows
both sway, gnome-shell and gtk+ to do the right thing, and I don't see
any reason for making it more complicated.


Jonas

> 
> Cheers,
> 
> -- 
> 
> Quentin “Sardem FF7” Glidic