[PATCH RFC] Add tiled states per edge

[Benoit Gschwind]

Hello,

more random comments below :)

On 08/07/2016 11:58, 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.
> 
> 
> 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).

imo, you are wrong above. The client do not have to obey the geometry,
this was avoided in the previous protocol specification where client can
"ignore" configure events arguments (even if he must reply to a
configure events). If the client do not comply, the compositor have
several choice like: centering, clipping or stretching the client. Thus
requiring the client to obey the geometry is not required.

"MUST" have a strong meaning within specification.

Another thing is "Resizing is initiated by the compositor only" is just
useless, the compositor is free to ignore move/resize request from clients.

Taken all comment above you get :

A "tiled" state where client should drop decoration and shadow.

This look like a "compositor-decorated-state" :)

Best regards
--
Benoit Gschwind

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