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
_______________________________________________
wayland-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
