GNOME Bugzilla – Bug 746273
GTK doesn't support partial maximization
Last modified: 2018-05-02 16:27:44 UTC
The setting of org.gnome.desktop.wm.preferences.action-double-click-titlebar is ignored by applications using the new title bar. This includes Evince and Files (nautilus). Specifically, I have used the dconf-editor to set org.gnome.desktop.wm.preferences.action-double-click-titlebar to toggle_maximize_vertically When using applications such as Terminal, double clicking on the titlebar correctly does a vertical only maximization. However, when using Evince and Files. double clicking on the titlebar maximizes both vertically and horizontally, contrary to the configured setting. Terminal seems to be using the old style title bars, while Evince and Files are using the new style title bars. In other words, org.gnome.desktop.wm.preferences.action-double-click-titlebar is selectively and incorrectly ignored by Mutter. Running on Fedora 21 x86-64. mutter-3.14.3-1.fc21.x86_64 evince-3.14.1-8.fc21.x86_64 nautilus-3.14.2-1.fc21.x86_64
For client-side decorated windows, the application is doing the window management, not mutter, and it's up to the application to follow or not follow mutter's preferences.
I'm not sure I understand which component is responsible for the bug. For client-side decorated windows, are double clicks on title-bars handled by GTK+, or directly by Evince, Files, etc? I don't want the maximize-vertically option to go away when the switch to Wayland occurs. I find this functionality very useful.
(In reply to Mark from comment #2) > For client-side decorated windows, are double clicks on title-bars handled > by GTK+, or directly by Evince, Files, etc? All the applications you listed use GTK+'s support for client-side decorations, and the handling is done by GTK+[0]. Other applications like Chromium do the handling themselves. [0] https://git.gnome.org/browse/gtk+/tree/gtk/gtkwindow.c#n1365
> All the applications you listed use GTK+'s support for client-side > decorations, and the handling is done by GTK+ Thanks for the clarification. Looking at the code in the link you provided (gtkwindow.c), lines 1393-1395 have: /* treat all maximization variants the same */ else if (g_str_has_prefix (action, "toggle-maximize")) _gtk_window_toggle_maximized (window); Is this the bug? > Other applications like Chromium do the handling themselves. Does this also mean that KDE applications running in Gnome shell (in a Wayland session) would also have this problem? (I use Gnome shell with a few KDE apps such as kwrite and kate) Would it make sense to have some sort of common handling of window resizes, maximisations, etc, shared across Gnome and KDE apps ? I don't know the exact interaction between Gnome shell and KDE apps when it comes to client-side decorations, so I'm stabbing in the dark here.
mclasen changed the severity tag to "enhancement". But isn't this a regression, instead of an enhancement? In previous versions of evince, nautilus + etc, double clicking on the title allowed vertical-only maximization. This no longer works, so it would be more precise to label this problem as a regression. Setting the Titlebar Actions can be done by gnome-tweak-tool, which indicates that vertical-only maximization is a supported part of Gnome.
I totally understand that you consider this a regression in the applications. But GTK+ has never supported this. Don't take what gnome-tweak-tool shows as a sign of official support - it is exactly that: tweaks that are _outside_ of what we officially support. We still don't break things willy-nilly. At the end of the day, enhancement vs regression doesn't make a huge amount of difference. If somebody produces a patch, it will be looked at.
> I totally understand that you consider this a regression in the > applications. But GTK+ has never supported this. > Don't take what gnome-tweak-tool shows as a sign of official support > - it is exactly that: tweaks that are _outside_ of what we officially > support. We still don't break things willy-nilly. In the context of the upcoming switch to Wayland, this issue has the potential to affect more applications. If everything under Wayland will use client-side decorations, then applications such as Terminal will also end up with this regression. The maximize-vertically feature has been present for many years in Gnome. While it's currently not supported by GTK, it is provided by Mutter. This in effect sets up an implied expectation that it will still work when the changeover to Wayland occurs. In all likelihood many people use this feature.
It is not like half-tiling windows is not supported anymore. The 'official' ways to half-tile windows are - drag the window to the edge - use the Super-left/right keybindings
(In reply to Matthias Clasen from comment #8) > The 'official' ways to half-tile windows are > - drag the window to the edge > - use the Super-left/right keybindings Half-tiling is useful, but it is not a replacement for the maximize-vertically functionality. It's related to, but clearly distinct from half-tiling. I'd like to see the functionality for maximize-vertically retained -- I use it every day.
(In reply to Marcus Vetter from comment #9) > I'd like to see the functionality for maximize-vertically retained -- I use > it every day. maximize vertically still works fine if you activate it through a keybinding. You can use Settings > Keyboard > Shortcuts > Windows to configure one.
(In reply to Rui Matos from comment #10) > maximize vertically still works fine if you activate it through a > keybinding. You can use Settings > Keyboard > Shortcuts > Windows to > configure one. That's not the point. It was previously possible to double click on the window title to maximize vertically. This functionality is now gone. A keyboard replacement for a mouse based function is not a fix.
Myself personally, I can not recall ever seeing this happen when I double clicked an already maximized window or a non-maximized window. I cant think of a time where it happened vertically or horizontally, so I was wondering if you could provide a way to reproduce this behavior? What distro/gnome-shell version? This would seem weird if it ever happened and I would much rather have the ability to have horizontal half-tiling along with edge snapping. Bring back 4-way tiling. For instance by dragging to the bottom of the screen now that it's gone and allow resorting once two are half-tiled in this manner. What is the point of vertical max on double click where you could then drag it around? You would have to resize to have 2 or more open this way right? If edge snapping was built on and allowed the ability to drag the snapped window in only horizontal or vertical fashion, wouldnt that suffice?
*** Bug 750939 has been marked as a duplicate of this bug. ***
Most window managers (even including older versions of metacity I think), support one-way maximizing by right- or middle-clicking on the maximize button. When it was asked for this feature to be restored/retained in GNOME the devs said that they considered doing that consistently with other window managers to be inconsistent with GNOME, but they obviously felt it was useful enough to enable it provided you were forced to use a different set of click actions. That's gnome.org logic for you.
This functionality is still broken in Gnome 3.16. It would be great to have this fixed in 3.18
> That's gnome.org logic for you. These kinds of comments have an effect, but it is probably not the one you want.
(In reply to Matthias Clasen from comment #16) > > That's gnome.org logic for you. > > These kinds of comments have an effect, but it is probably not the one you > want. I'm sorry, I didn't mean to offend anyone but I should have considered that GNOME is made up of people. I had probably been peed off by something else that day and vented my frustration in the wrong direction. I'm sure you can identify with that.
It would be really nice to have this fixed. I recently switched to GNOME on Wayland, and now my titlebar action of "maximize vertically" is not respected.
*** Bug 773056 has been marked as a duplicate of this bug. ***
(In reply to Mark from comment #4) > Looking at the code in the link you provided (gtkwindow.c), lines 1393-1395 > have: > > /* treat all maximization variants the same */ > else if (g_str_has_prefix (action, "toggle-maximize")) > _gtk_window_toggle_maximized (window); > > Is this the bug? It's not really a bug if it's explicitly commented as being intentional... it's just a feature that no one has coded yet. :P > > Other applications like Chromium do the handling themselves. > > Does this also mean that KDE applications running in Gnome shell (in a > Wayland session) would also have this problem? (I use Gnome shell with a > few KDE apps such as kwrite and kate) I doubt it. The issue is that GTK+ client-side decorations don't react to clicks in the way that some people want (and can never react in the way that everyone would want). (In reply to Tony Houghton from comment #14) > Most window managers (even including older versions of metacity I think), > support one-way maximizing by right- or middle-clicking on the maximize > button. I prefer the ones that let the user configure that double-clicking on a horizontal or vertical edge (when the resize cursor is shown) will cause maximisation along that axis.
Ubuntu is also tracking this issue in: https://bugs.launchpad.net/bugs/1698083
> (In reply to Tony Houghton from comment #14) > > Most window managers (even including older versions of metacity I think), > > support one-way maximizing by right- or middle-clicking on the maximize > > button. > > I prefer the ones that let the user configure that double-clicking on a > horizontal or vertical edge (when the resize cursor is shown) will cause > maximisation along that axis. I wasn't aware of that. It's easier than having to remember which button or double vs single corresponds to which direction, so I'd welcome GTK behaving that way.
(In reply to Daniel Boles from comment #20) > I doubt it. The issue is that GTK+ client-side decorations don't react to > clicks in the way that some people want (and can never react in the way that > everyone would want). Why not? If it were configurable (.gtkrc?), GNOME tweak tool could make the GTK behavior (for client side decorations) and Mutter behavior (for WM-provided decorations) match up, so it works the same in either case. While configuration options can be annoying, it seems even more unfortunate to hardcode a policy. In effect, client side window decorations are making GTK handle part of the job that the window manager traditionally performed, and so it would be really nice if it were possible to make it follow the same behavior as those window managers. I suppose you won't get /everyone/'s preference, but at least a few common ones (maximize/maximize vertically/shade) would probably cover the majority of cases...
*** Bug 787220 has been marked as a duplicate of this bug. ***
*** Bug 795055 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/539.