GNOME Bugzilla – Bug 789357
Regression in 3.22.23: GDK_WINDOW_STATE_TILED flag is never set
Last modified: 2018-05-02 19:22:41 UTC
gnome-terminal has special cases for when it is maximized or tiled (half-maximized) to turn off the character-cell-based resizing logic (Bug #760944). Since GTK+ 3.22.23 and Mutter 3.26.1, these special cases are ineffective, because GTK+ now sets 0-4 hints like GDK_WINDOW_STATE_TOP_TILED instead of a single hint GDK_WINDOW_STATE_TILED. The plain TILED state is now deprecated, and as far as I can see it is never activated. This is a regression for apps that were relying on it (see Bug #789356 for the effects this has on gnome-terminal, which are quite annoying). If all four edges are considered to be TILED, then the deprecated TILED state should certainly be activated. This would make existing/older versions of gnome-terminal (and similar character-cell-based apps) fill their assigned space. If between 1 and 3 edges are considered to be TILED, I'm not sure whether the deprecated TILED state should be set or not. I think the conservative answer would probably be to set it. I've opened Bug #789356 in gnome-terminal as well as opening this bug, because I suspect the most robust fix would be to address this at both ends: fix the regression in GTK+, and stop relying on the deprecated state flag in gnome-terminal.
Relatedly, several parts of GTK+ use the now-deprecated TILED state to change their behaviour: * GdkWindowImplWayland and GtkWindow ignore GDK_HINT_RESIZE_INC when constraining the window size if the window is maximized, fullscreen or TILED, but not if it has individual edges tiled * GdkWindowImplX11 ignores potential unmaximization if the window isn't MAXIMIZED or TILED, but doesn't ignore potential unmaximization if the window has individual edges tiled (I don't know whether this can really happen though) * GtkHeaderBar updates the header-bar buttons if the old TILED state has changed, but not if individual edges' tiled states have changed * GtkWindow doesn't set the old "tiled" style context class if individual edge tiling information is available, which potentially breaks themes? For GDK_HINT_RESIZE_INC, unmaximization and the "tiled" style context class, I think the conservative thing to do would be to consider the window to be TILED if at least one edge is tiled. For the header-bar, we should probably consider updating the header-bar buttons whenever any of the tiling flags (the old one or the four new ones) have changed.
(In reply to Simon McVittie from comment #1) > For GDK_HINT_RESIZE_INC, unmaximization and the "tiled" style context class, > I think the conservative thing to do would be to consider the window to be > TILED if at least one edge is tiled. > > For the header-bar, we should probably consider updating the header-bar > buttons whenever any of the tiling flags (the old one or the four new ones) > have changed. I'm testing patches that do these.
Created attachment 362359 [details] [review] [1/3] Set GDK_WINDOW_STATE_TILED if any edge is tiled This state flag is used in several places in GTK+, for example to ignore RESIZE_INC hints if tiled. Setting it is also necessary for backwards compatibility with applications that changed their behaviour when tiled, such as GNOME Terminal and its MATE fork.
Created attachment 362360 [details] [review] [2/3] GtkHeaderBar: Reconsider buttons if any tiling state changes Looking at the 1-bit "tiled or not?" state is not necessarily enough.
Created attachment 362361 [details] [review] [3/3] GtkWindow: Set tiled class on windows that have any tiled edge This has no practical effect on Adwaita, but might fix some third-party themes that were broken by GTK+ 3.22.23.
Review of attachment 362359 [details] [review]: Looks good for GTK+ 3. Notice that, for GTK+ 4, I believe the plan is to drop TILED entirely and just use the edges.
Review of attachment 362360 [details] [review]: That was an overlook from my initial patchset, so ++.
Review of attachment 362361 [details] [review]: Ok... Not going to GTK4, but good to keep stability for GTK3
Thanks for your patches
(In reply to Georges Basile Stavracas Neto from comment #6) > Looks good for GTK+ 3. Notice that, for GTK+ 4, I believe the plan is to > drop TILED entirely and just use the edges. If that is going to happen, great. If TILED is going to remain present, I think it would be confusing for it to mean something other than what it meant in GTK3 without clear documentation that this is the case: so I'd suggest either removing the enum member completely, or applying this change for now (until it's actually removed), or documenting the differing semantics. (In reply to Georges Basile Stavracas Neto from comment #8) > Ok... Not going to GTK4, but good to keep stability for GTK3 I assume GTK4 themes aren't generally expected to be compatible with GTK3 themes anyway?
(In reply to Simon McVittie from comment #1) > * GdkWindowImplWayland and GtkWindow ignore GDK_HINT_RESIZE_INC when > constraining the window size if the window is maximized, fullscreen or > TILED, but not if it has individual edges tiled > > * GdkWindowImplX11 ignores potential unmaximization if the window isn't > MAXIMIZED or TILED, but doesn't ignore potential unmaximization if the > window has individual edges tiled (I don't know whether this can really > happen though) For GTK4, if the plan is to remove TILED completely, then check_unmaximize() in GdkWindowImplX11, gtk_window_constrain_size() in GtkWindow and xdg_surface_configure() in GdkWindowImplWayland will need to use the individual tiling flags rather than the old TILED to check whether to apply their special-cases, a lot like Attachment #362360 [details]. For GTK3 I went with the simpler solution of always setting TILED correctly since it's part of the API anyway, but if it goes away or if Attachment #362359 [details] isn't going to be applied, then its users elsewhere in GTK will have to adapt. (Sorry, no patch for this part, I don't have a GTK4 test environment.)
-- 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/959.