[PATCH RFC] xdg-shell: Add tiled states

[Mike Blumenkrantz]

On Wed, Jun 1, 2016 at 10:42 AM Olivier Fourdan <ofourdan at redhat.com> 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'll ask you to clarify which "tiling" you're referring to in this case; I
don't believe that gtk's toolkit implementation of a single state for two
separate functionalities should dictate the protocol in this case.


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

You're conflating different issues again, I think. On client-side, maximize
is typically only initiated using a window decoration button. Other forms
of maximize (e.g., partial maximizes) are compositor maximizes, and I think
this is a significant difference to note.
I imagine that you aren't advocating adding enough buttons to your
application/toolkit UI to enact all the maximize/tile states that you've
proposed, so this is purely a question of compositor policy vs client-side
internals. What you've cited in your case looks to just be an
implementation bug in your toolkit; Enlightenment/EFL have handled both
tiling layout policies and partial maximize states since before the E17
release, so that's sufficient proof for me that it's doable.


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

I obviously don't have as much experience writing applications for your
desktop/toolkit UX standards, but it seems like having one side of a window
square and another side round is not going to look very good. Certainly
it's not something I plan on implementing in EFL at any point.


>
> > 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).
>
> 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
>
>
Enlightenment has a functioning tiling layout policy, so I've been chiming
in from that perspective as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160601/5de582a5/attachment.html>