On Wed, Jun 1, 2016 at 10:42 AM Olivier Fourdan <[email protected]> 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.
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
