[PATCH RFC] xdg-shell: Add tiled states

[Jonas Ådahl]

On Wed, Jun 01, 2016 at 10:42:23AM -0400, Olivier Fourdan wrote:
> Hi Mike,
> 
> ----- Original Message -----
> > I've read the ticket linked in the other mail, but your use of "tiled" here
> > is confusing to me since you (and the ticket) appear to be conflating two
> > separate-but-unrelated meanings.  "Tiled" is a type of window layout policy
> > which organizes windows into a tiled grid formation; this is in opposition
> > to "stacking".
> 
> Sure, I appreciate that.
>  
> > The ticket you linked seems to be primarily about positioning windows to
> > take up 50% of screen geometry, (e.g., left half of screen, top half of
> > screen, ...). This seems a lot more like a maximize state to me since it's
> > based on screen geometry. In X11 there's NETWM hints for
> > vertical/horizontal maximize: EFL uses these to handle partial
> > maximizations, and in Wayland we simply use the normal MAXIMIZE window
> > state since directionality is irrelevant.
> 
> This is the current use of "tiling" in gnome-shell and gtk+, but we should not limit tiling to a single (very limited) implementation.
> 
> > I think MAXIMIZE fully covers
> > this case and there is no need for any further protocol to inform the
> > client.
> 
> I reckon using partial maximization from EWMH to achieve basic tiling in gnome-shell/gtk+ was a hack, it leads to all sort of workarounds in gtk+:
> 
> https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkdisplay-x11.c#n244
> 
> And it doesn't even take into account horizontal tiling, https://bugzilla.gnome.org/show_bug.cgi?id=742525
> 
> I'd rather not mix up maximization and tiling again, given the chance...
> 
> > In the case of the real "tiled" state, (i.e., a tiling layout policy), I
> > think this is something which should be a single draw state. There's no
> > need to inform a client about its surface's relative position (e.g., any of
> > your proposed directional tiled values) since the result is the same in
> > every case--the client must obey configured geometry.
> 
> The client may chose to draw the border on the surface edged tiled differently, to achieve seamless borders between tiled windows for example, while keeping the other edges (not tiled) unchanged, that was the idea behind the use of the edge values.
>  
> > The difference from the MAXIMIZE state here is mostly conceptual: MAXIMIZE
> > indicates to a client that a surface is taking up the entire screen's
> > geometry on at least one axis and thus it may choose to draw UI elements
> > differently (e.g., showing/hiding extra toolbars along the larger axis). A
> > TILED state simply informs the client that it must obey sizing policies and
> > draw rectangular borders. A MAXIMIZED surface cannot be tiled (since it's
> > implicitly "tiled" by being maximized), but a tiled surface can toggle
> > MAXIMIZE.
> 
> I see where you're coming from, if we consider a single "tiled" state then it's similar in essence to the maximized state with a different geometry, so we could get away with a "tiled" draw state instead that clients would use to distinguish from the real "maximize" state when drawing their decorations (including the "maximize" button in the title bar which can differ when maximized or not).

I fail to see what makes tiling and maximized so significantly different
that one would require a predictable negotiation. This would just mean
that a tiling compositor can't properly tile surfaces that doesn't
support an optional draw state.

If the tiling compositor still would draw the surface tiled which didn't
support the tiled draw state, then I see no point what so ever having to
negotiate anything, since the end result for the compositor would be
100% the same.

So, what is the reason a tiled state an optional state that requires
negotiation, while maximized does not?


Jonas

> 
> Granted, I am not a tiling window manager aficionado myself, so it would be great if those who design tiling window managers could chime in as well and express their needs wrt. tiling.
> 
> Cheers,
> Olivier
> 
>  
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel