Re: [PATCH RFC] Add tiled states per edge
Hello, more random comments below :) On 08/07/2016 11:58, 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. > > > 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). imo, you are wrong above. The client do not have to obey the geometry, this was avoided in the previous protocol specification where client can "ignore" configure events arguments (even if he must reply to a configure events). If the client do not comply, the compositor have several choice like: centering, clipping or stretching the client. Thus requiring the client to obey the geometry is not required. "MUST" have a strong meaning within specification. Another thing is "Resizing is initiated by the compositor only" is just useless, the compositor is free to ignore move/resize request from clients. Taken all comment above you get : A "tiled" state where client should drop decoration and shadow. This look like a "compositor-decorated-state" :) Best regards -- Benoit Gschwind > > GNOME will use the "maximized" state, because it really is that, but > with a variation: we add some "you-can-draw-stuff-on-" draw > states, only meaningful in the "maximized" state. > 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. > > How are you feeling about it? > > > 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. > > 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. > > > I hope it makes things a little clearer, and hopefully lead us to a > final decision. > > Cheers, > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH RFC] Add tiled states per edge
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-" 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
Re: [PATCH RFC] Add tiled states per edge
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-" 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 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
Re: [PATCH RFC] Add tiled states per edge
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. 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-" draw states, only meaningful in the "maximized" state. 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. How are you feeling about it? 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. 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. I hope it makes things a little clearer, and hopefully lead us to a final decision. Cheers, -- Quentin “Sardem FF7” Glidic ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH RFC] Add tiled states per edge
Hi all, I send this as an RFC for now, to gauge the water and get the ball rolling. I don't think tiling overlaps with the "draw states" proposed by Mike in the other thread currently on wayland-devel, I reckon tiling is more than just drawing, applications must obey the configure event when tiled, just like when maximized or fullscreen. They may also change their decorations, of course, but not only. This takes ideas from Jonas and Matthias, as discussed in GNOME bug #766860. Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=766860 Olivier Fourdan (1): xdg-shell: Add tiled states unstable/xdg-shell/xdg-shell-unstable-v6.xml | 27 +++ 1 file changed, 27 insertions(+) -- 2.7.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
