Hello, simple random comment bellow :)
On 08/07/2016 12:16, Jonas Ådahl wrote: > On Fri, Jul 08, 2016 at 11:58:13AM +0200, Quentin Glidic wrote: >> Hi all, >> >> I will try to summarize all the discussion about tiling that this thread has >> generated, and if all goes fine, we will see that we mostly all agree with >> each other. >> >> First, definitions: >> >> Stacking/Floating: this is the “classic” way of managing windows, directly >> inherited from the desktop metaphor. Windows goes “on top of each other”, so >> you cannot see the ones below without moving the ones on the front. >> >> Tiling: a rather well-known paradigm, where windows do not hide each other. >> Most of the time, it’s coupled with the idea that no screen space should be >> wasted, but it is not mandatory (see e.g. i3-gaps or even Sway IIRC). >> >> Maximize: this concept is mostly tied to stacking/floating, as it is meant >> to make one window cover all others (by covering the whole screen, except DE >> UI). This state is temporary, as focusing another window will break it. >> It breaks the *feature* (covering all other windows), not the window state; >> but a WM/compositor could revert that state. >> >> >> Now, let’s see who is using which terms. >> >> From what Mike said, E(nlightenment) supports both stacking/floating and >> tiling. >> In GNOME(-Shell), there is “partial tiling”. With a (few) keystroke(s) you >> can put two windows side-by-side on one screen. >> In i3, Sway and any tiling window manager/compositor, tiling is there, with >> usually basic support for stacking/floating, mostly for dialogs or to >> workaround bad behaving clients (Java, Steam). >> I am not familiar enough with KDE so I’ll skip it, sorry. :-) >> >> As we can see, GNOME is the outstanding one. >> GNOME is using stacking/floating management, no “true” tiling here. The >> “partial tiling” feature is actually, as Mike said, “partial maximize”: a >> temporary “covering part of my screen” feature. > > The tiling code is being worked on to add more tiling configurations. > Don't confuse it with maximize, thats something else. > >> >> >> Another relevant point: clients tend to use shadows as resize handlers >> nowadays. >> >> There is a need to tell clients there are tiled (as in “real” tiling), but >> is this the same need as “partial tiling”? >> It seems obvious to me that the non-GNOME answer is “no”. >> >> >> Now, here is my proposal: >> >> A single "tiled" state, for “real” tiling. The client must obey the geometry >> and drop the decorations and shadows. Resizing is initiated by the >> compositor only (either to tile or by explicit user resize action). >> >> GNOME will use the "maximized" state, because it really is that, but with a >> variation: we add some "you-can-draw-stuff-on-<edge>" draw states, only >> meaningful in the "maximized" state. > > No. Lets not bring draw states (I'm more and more thinknig its the wrong > name, its not related to the window states, if you think you want to add > any entry to the draw states enum, the answer is quite likely "no"). > > Also no, using maximized is a work-around for the lack of any "tiled" > window state. The GNOME tiling state is, as I said, maximized. > >> This means the normal non-maximized draw state is “you can draw >> shadows/borders”, but once maximized, you have to negotiate to still render >> shadows/borders on the potential non-maximized edges. > > There is no point in negotiating anything here. > >> >> How are you feeling about it? > > I see no reason for not just going with the initial approach by having > four tiling states. sway and other tiling compositors would always set > all sides as tiled. Half-screen tiled GNOME would set the edges it > considers "tiled" as tiled, and GTK+ can in both cases draw shadow etc > where it wants to. > > sway would never get any shadow, and would always deal with resizing of > all edges, as long as it keeps the windows tiled on all edges; it'll > work perfectly fine. gnome-shell is allowed to have its half tiled > state if it wants, or add 1/4 tiled or whatever. GTK+ would in both > cases know what to do, and both gnome-shell and sway get what they want. > >> >> >> Now, one last thing to think about: >> >> As we saw, maximize makes little sense in tiling, so clients should hide >> their maximize/unmaximize button. But Benoit thinks it can be of use. The >> minimize and close buttons are not actually that different. > > Maybe so. Lets not drag this into this discussion though (telling > clients whether to draw the maximize icon or not). > >> >> To me, these should be compositor-specific actions, rather than something >> clients are aware of. IMO, tiling is also “the compositor knows better”, and >> thus the client should not initiate actions. > > Indeed. We don't have any "tile me" request. We need a maximize request > because that is a very common thing to have. But lets not get into that > now. I would like to have this button "tile me", in `page' I use "bind/unbind" button to switch a surface between tiled mode (i.e. the surface is binded to a given tile) and floating mode (i.e. free moving surface). Best regards -- Benoit Gschwind > >> >> >> I hope it makes things a little clearer, and hopefully lead us to a final >> decision. > > Sure. As I said, going with the initial approach with four states allows > both sway, gnome-shell and gtk+ to do the right thing, and I don't see > any reason for making it more complicated. > > > Jonas > >> >> Cheers, >> >> -- >> >> Quentin “Sardem FF7” Glidic > _______________________________________________ > wayland-devel mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
