Hello Jonas, The things I see for maximized vs. tilling: - tilling window does not need a unmaximize button, because they are not maximized; - tilling window may want to switch maximized and draw the corresponding button; - tilling window may not need close button to be drawn.
We will quickly end up to _NET_WM_ALLOWED_ACTIONS :) Side note: I'm using my own hand written tilling window manager named page. Best regards. On 02/06/2016 03:01, Jonas Ådahl wrote: > 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@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/wayland-devel > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
