<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 1, 2016 at 10:42 AM Olivier Fourdan <<a href="mailto:ofourdan@redhat.com">ofourdan@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Mike,<br>
<br>
----- Original Message -----<br>
> I've read the ticket linked in the other mail, but your use of "tiled" here<br>
> is confusing to me since you (and the ticket) appear to be conflating two<br>
> separate-but-unrelated meanings.  "Tiled" is a type of window layout policy<br>
> which organizes windows into a tiled grid formation; this is in opposition<br>
> to "stacking".<br>
<br>
Sure, I appreciate that.<br>
<br>
> The ticket you linked seems to be primarily about positioning windows to<br>
> take up 50% of screen geometry, (e.g., left half of screen, top half of<br>
> screen, ...). This seems a lot more like a maximize state to me since it's<br>
> based on screen geometry. In X11 there's NETWM hints for<br>
> vertical/horizontal maximize: EFL uses these to handle partial<br>
> maximizations, and in Wayland we simply use the normal MAXIMIZE window<br>
> state since directionality is irrelevant.<br>
<br>
This is the current use of "tiling" in gnome-shell and gtk+, but we should not limit tiling to a single (very limited) implementation.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> I think MAXIMIZE fully covers<br>
> this case and there is no need for any further protocol to inform the<br>
> client.<br>
<br>
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+:<br>
<br>
<a href="https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkdisplay-x11.c#n244" rel="noreferrer" target="_blank">https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkdisplay-x11.c#n244</a><br>
<br>
And it doesn't even take into account horizontal tiling, <a href="https://bugzilla.gnome.org/show_bug.cgi?id=742525" rel="noreferrer" target="_blank">https://bugzilla.gnome.org/show_bug.cgi?id=742525</a><br>
<br>
I'd rather not mix up maximization and tiling again, given the chance...<br></blockquote><div><br></div><div>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.</div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> In the case of the real "tiled" state, (i.e., a tiling layout policy), I<br>
> think this is something which should be a single draw state. There's no<br>
> need to inform a client about its surface's relative position (e.g., any of<br>
> your proposed directional tiled values) since the result is the same in<br>
> every case--the client must obey configured geometry.<br>
<br>
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.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> The difference from the MAXIMIZE state here is mostly conceptual: MAXIMIZE<br>
> indicates to a client that a surface is taking up the entire screen's<br>
> geometry on at least one axis and thus it may choose to draw UI elements<br>
> differently (e.g., showing/hiding extra toolbars along the larger axis). A<br>
> TILED state simply informs the client that it must obey sizing policies and<br>
> draw rectangular borders. A MAXIMIZED surface cannot be tiled (since it's<br>
> implicitly "tiled" by being maximized), but a tiled surface can toggle<br>
> MAXIMIZE.<br>
<br>
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).<br>
<br>
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.<br>
<br>
Cheers,<br>
Olivier<br>
<br></blockquote><div><br></div><div>Enlightenment has a functioning tiling layout policy, so I've been chiming in from that perspective as well.</div><div> </div></div></div>