[PATCH RFC] Add tiled states per edge

[Benoit Gschwind]

Hello,

simple random comment bellow :)

On 08/07/2016 12:16, Jonas Ådahl wrote:
> 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 would like to have this button "tile me", in `page' I use
"bind/unbind" button to switch a surface between tiled mode (i.e. the
surface is binded to a given tile) and floating mode (i.e. free moving
surface).

Best regards
--
Benoit Gschwind

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