(In reply to Simon McVittie from comment #0)
> 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. It no longer sets the plain TILED hint
> (which I think is a regression, and I'll open a separate bug for that).

Bug #789357.

The plain TILED state is now considered to be deprecated, so it's probably best (and certainly more robust) to fix gnome-terminal to not rely on it, as well as fixing the regression.

I added the new states under a gtk version check. Please test if that fixes the problem.

(In reply to Christian Persch from comment #2)
> I added the new states under a gtk version check. Please test if that fixes
> the problem.

Thanks, your change is what I had in mind. I'll test this later.

This won't fix the regression for cases where gnome-terminal was built against an old GTK+, then GTK+ was subsequently upgraded; but that can only be fixed from the GTK+ side anyway (Bug #789357).

This partially fixes the reported regression, but not completely :-(

With your patch applied (to 3.26.1), zooming the window in or creating a second tab no longer pushes window content off-screen - the window is correctly bounded by the screen size. Zooming out also keeps the window the same size. So that's good; making the handling of the TILED flag backwards-compatible does help a lot.

However, the window still doesn't go all the way to the edge of the screen, like it did with in older versions of Shell and GTK+. It seems to cut off at a character-cell boundary. I'm not sure what the root cause is for this part.

(In reply to Simon McVittie from comment #4)
> However, the window still doesn't go all the way to the edge of the screen,
> like it did with in older versions of Shell and GTK+. It seems to cut off at
> a character-cell boundary. I'm not sure what the root cause is for this part.

I would guess that's a mutter/gnome-shell problem, probably it still applies all geometry hints even in the tiled direction?

Nice, thanks!

(I was secrecly hoping this patch would also fix or work around bug 751064; it doesn't.)

If you change font size, an additional gap appears within gnome-terminal (due to the window size no longer being an aligned one), and the two gaps altogether could easily be large enough for yet another row. Whereas if you add/remove the second tab, g-t window's height is adjusted.

Can we improve gnome-terminal (so that it does the same on font zoom as it does now when opening a second tab)? Or would it introduce problems with non-maximized windows? Also, should it be necessary at all, or should mutter/gnome-shell change its behavior instead?

I believe it would be better if mutter/gnome-shell enforced the maximum (not necessarily grid-aligned) height for half-maximized windows, just as it does with fully maximized ones. It could keep doing so even if the user drags the only dragbar the window's border has, the one at the middle of the screen. Horizontal resizing could still respect the grid regardless of the height being non-aligned.

And by the way, with the smooth scrolling feature (vte-0.44) gnome-terminal can actually utilize that gap at the bottom when scrolling back. It prefers not to have that gap, but if it has, it uses it.

It's also ugly that right-half-maximized windows, if their width is not exactly the half of the screen, leave a gap at the right edge of the screen rather than being pushed all the way to the right.

I think these issues should be filed against m/g-s.

Resizing at the divider works perfectly with two half-maximized xterms used via XWayland (modulo a little bit of lag where the one not being resized doesn't always catch up instantly), which I suspect might indicate that if the stepped-resize property went back to being a hint that was set on the window by gnome-terminal and enforced by Mutter/Shell rather than being gnome-terminal second-guessing how resizing works, it would work better?

(But that would probably require GTK+ to un-deprecate gtk_window_set_geometry_hints() and make it do something again, and presumably the GTK+ maintainers don't want that.)

(In reply to Simon McVittie from comment #8)

> [...] if
> the stepped-resize property went back to being a hint that was set on the
> window by gnome-terminal and enforced by Mutter/Shell rather than being
> gnome-terminal second-guessing how resizing works [...]

I'm not following you here...

gnome-terminal still properly [khmm, see my next comment] sets the geometry hints, mutter/gnome-shell or any other window manager should reasonably respect them. There's no second-guessing.

> (But that would probably require GTK+ to un-deprecate
> gtk_window_set_geometry_hints() and make it do something again, and
> presumably the GTK+ maintainers don't want that.)

gtk_window_set_geometry_hints() is not deprecated. It stopped working on widgets (e.g. VTE) but still works on the entire window. Hence some code that was removed from GTK+ had to be re-added to gnome-terminal. This change should be a private business of the GTK+ + gnome-terminal couple, and shouldn't be visible outside (e.g. to the window manager). As such, for the currently remaining issues, it's irrelevant.

The recent commit 2f33a36 introduced a regression/bug.

When the window is half-maximized (most likely full-maximized is also affected, haven't checked) and the font size is changed, the geometry hints are not updated correctly.

As a result:

- dragging at the vertical edge at the middle of the screen jumps with incorrect increments;

- after restoring the original size, resize increments are still incorrect.

I believe gnome-terminal should always, unconditionally maintain the correct geometry hints (base & resize increments), even in maximized and tiled modes. That's the only way a window manager can reasonably implement resizing of the half-maximized windows, or unmaximizing to a proper (grid-aligned) size. Also, that's the only reasonable API I could imagine between the two components. If gnome-terminal ever delays (let alone forgets) to update the hints, it's probably already too late to do it upon an unmaximize or such event.

On top of this, the window manager should be responsible for maintaining the maximized or half-maximized state of the windows, ignoring geometry hints (and changes thereof) and presumably overriding app-initiated resizes as well.

My _feeling_ about this recent patch (I might easily be wrong, I haven't taken a closer look) is that for partially tiled windows we no longer:

- resize the window immediately;

- update the geometry hints.

What I believe should happen instead is that we still update the hints, although don't resize the window.

We already have this behavior at a couple of not so important places where we were lazy to code up the correct behavior, e.g. when the scrollbar's visibility is toggled (on non-maximized windows).

(In reply to Egmont Koblinger from comment #10)
> I believe gnome-terminal should always, unconditionally maintain the correct
> geometry hints (base & resize increments), even in maximized and tiled
> modes.
...
> What I believe should happen instead is that we still update the hints,
> although don't resize the window.

That certainly makes sense conceptually. So the terminal_window_update_geometry() call in terminal_window_update_size() should move up above the early-return?

(In reply to Egmont Koblinger from comment #9)
> gnome-terminal still properly [khmm, see my next comment] sets the geometry
> hints, mutter/gnome-shell or any other window manager should reasonably
> respect them.

Sorry, I was misremembering. They weren't deprecated and turned into a stub; as you say, that was only for the case where the hints are set on individual non-window widgets. However, in Wayland, GDK_HINT_RESIZE_INC isn't communicated to the compositor either. Instead, it's used to constrain the window size on the client side.

Unfortunately, several parts of GTK+ seem to have the same bug that commit 2f33a36 fixed: they only look for the TILED flag, and not the individual edges. In particular, the code that ignores GDK_HINT_RESIZE_INC for tiled windows hasn't been updated to account for the new flags.

(In reply to Simon McVittie from comment #11)

> So the
> terminal_window_update_geometry() call in terminal_window_update_size()
> should move up above the early-return?

Seems as easy as that, yup, thanks. Let's wait for Christian to double check.

(In reply to Simon McVittie from comment #12)

> However, in Wayland, GDK_HINT_RESIZE_INC isn't
> communicated to the compositor either. Instead, it's used to constrain the
> window size on the client side.

I didn't know about this one. Does it mean that _some_ of the issues we're seeing might need to be fixed in GTK+ rather than wayland/gnome-shell/mutter?

Anyways, it's definitely the window manager (compositor, whatever, I'm not sure what's the right term) that knows for sure that window's been half-maximized, and is supposed to force maintain that state. Correct?

Re the two previous answers:

The proposed "fix" of comment #11 causes the half-maximized window to shrink on every zoom change (grid alignment is enforced). That's a bad user experience. It needs to be combined with a modified behavior of the compositor then, to enforce the previous (no longer aligned) size. Hmmm, is this the right approach?

(In reply to Egmont Koblinger from comment #14)
> I didn't know about this one. Does it mean that _some_ of the issues we're
> seeing might need to be fixed in GTK+ rather than wayland/gnome-shell/mutter?

Yes. Please see Bug #789357.

> Anyways, it's definitely the window manager (compositor, whatever, I'm not
> sure what's the right term) that knows for sure that window's been
> half-maximized, and is supposed to force maintain that state. Correct?

Sort of. The compositor can map the app's window wherever it wants to, but the app has total control over what it draws, and in gnome-terminal's case, what it draws is currently slightly smaller than the space available.

On a somewhat related note: see also bug 731137. (Ignore the long discussions there, they lead nowhere. Just the first few posts and my recent comment.)

(In reply to Egmont Koblinger from comment #15)
> The proposed "fix" of comment #11 causes the half-maximized window to shrink
> on every zoom change (grid alignment is enforced). That's a bad user
> experience. It needs to be combined with a modified behavior of the
> compositor then, to enforce the previous (no longer aligned) size.

I think (hope) this is happening because GTK+ now respects GDK_HINT_RESIZE_INC in GdkWindowImplWayland and GtkWindow even when tiled, whereas it previously ignored that hint when tiled. So every time our window size changes, GTK+ rounds it down to the next character cell boundary, which changes the size we think we're aiming for. When we change the zoom level again, the new size is probably not at an integer multiple of the new character cell size, so GTK+ rounds it down, and we gradually ratchet downwards.

Before the change I suggested in Comment #11, we dodged this by not even setting the hints while tiled, so there was nothing to tell GTK+ that it might want to round down.

If that guess is true, then we can avoid this by fixing GTK+ (Bug #789357) and not need to modify the compositor.

(In reply to Simon McVittie from comment #16)

> Sort of. The compositor can map the app's window wherever it wants to, but
> the app has total control over what it draws, and in gnome-terminal's case,
> what it draws is currently slightly smaller than the space available.

And, if I'm following you correctly, that's solely because of the aforementioned GTK+ bug, and not at all due to gnome-shell/mutter?

Since gnome-terminal uses the entire area in real maximized state, do I suspect correctly that it should be relatively easy to come up with a fix to GTK+ (pretty much along the lines of just replicating the four new LEFT_TILED etc. wherever TILED is present)?

Cross-posted my previous comment, seems you answered that.

The theories / your knowledge of how things are (or should be) pretty much explain the behavior we're experiencing, so the picture got much clearer to me :)

Even though the "fix" you suggested introduces another kind of regression, I believe that's the right path to start going. And then fix GTK+.

Now, g-t _could_ add a workaround against that shrinkage: it could remember the pixel size when it gets into tiled mode, and then manually enlarge if it sees room for yet another row/col based on that remembered size. Sounds nasty and I absolutely wouldn't want to do it.

---

There are 2 things I still don't understand, see bug 751064. They're both present regardless of the recent fix as well as the proposed followup.

- Maximize and unmaximize shrinks the terminal by 1x1.

- If you maximize and then half-maximize, the window is 1x1 smaller than if you half-maximize from normal state.

My blind guess is that in both cases somebody (who??) goes like "there's that extra padding right now, I assume it's going to be there even at the new window size" and so it leaves room for that; but then whoops due to aligning that extra gap is gone.

Egmont: Do you want to revert the commit here until the gtk bug is fixed?

I'm not sure what's the best to do for now.

(Maybe the best is to fix the GTK+ bug ourselves, and then push the devs to commit it ASAP. :))

(In reply to Egmont Koblinger from comment #22)
> (Maybe the best is to fix the GTK+ bug ourselves, and then push the devs to
> commit it ASAP. :))

I'm testing some patches for the GTK+ bug. I'll see whether they help gnome-terminal.

(In reply to Christian Persch from comment #21)
> Egmont: Do you want to revert the commit here until the gtk bug is fixed?

I would suggest keeping the gnome-terminal-side workaround until we know what GTK+ maintainers want to do about it.

I can see two possibilities. One is to acknowledge that not setting TILED is a regression, and go back to setting it whenever at least one edge is tiled: that would make 2f33a36 unnecessary (but harmless). This is the one I'm testing, because I think it's the more correct solution: it stops existing software (old gnome-terminals, mate-terminal, etc.) from regressing.

The other possibility is that the GTK+ maintainers continue to think that TILED should never be set on recent compositors, and change the places in GTK+ that rely on it to use TOP_TILED|LEFT_TILED|... instead. If they do that, then gnome-terminal will need to retain 2f33a36.

I personally think that the bug that 2f33a36 fixes (show tab bar => bottom lines of terminal extend below screen) is more annoying than what's described in Comment #10.

Continuing to set the hints even when tiled/maximized/full-screen (as suggested in Comment #11) is not going to work well until GTK+ is fixed, so let's come back to that later?

(In reply to Egmont Koblinger from comment #20)
> There are 2 things I still don't understand, see bug 751064. They're both
> present regardless of the recent fix as well as the proposed followup.
> 
> - Maximize and unmaximize shrinks the terminal by 1x1.

I can reproduce this, and it's still an issue after applying the patches I proposed on Bug #789357.

> - If you maximize and then half-maximize, the window is 1x1 smaller than if
> you half-maximize from normal state.

The patches I proposed on Bug #789357 avoids this: the window properly fills the space it's given.

> My blind guess is that in both cases somebody (who??) goes like "there's
> that extra padding right now, I assume it's going to be there even at the
> new window size" and so it leaves room for that; but then whoops due to
> aligning that extra gap is gone.

That sounds plausible. Client-side decoration requires gnome-terminal to keep track of three bounding boxes: vte widget; window content, i.e. vte widget + terminal chrome (menu bar, scrollbar, tabs) + any other padding; and X11 window or Wayland surface, i.e. window content + CSDs (including title bar and drop-shadow). Any time one of those changes without the TerminalWindow code noticing the change, it will cause incorrect sizing.

(In reply to Simon McVittie from comment #24)

> I personally think that the bug that 2f33a36 fixes (show tab bar => bottom
> lines of terminal extend below screen) is more annoying than what's
> described in Comment #10.

I didn't (mean to) describe it as non-annoying in #10, it must've been some misunderstanding. You're right, it's indeed a danm annoying bug if the bottom line is pushed offscreen, so sure, let's keep the workaround.

> Continuing to set the hints even when tiled/maximized/full-screen (as
> suggested in Comment #11) is not going to work well until GTK+ is fixed, so
> let's come back to that later?

Well, it only makes a difference when the font size changes, and the entire contents remain onscreen, so this one is lower priority. I'm not sure whether to go for the "better behavior now (until Gtk+ is fixed)" or the "technically more correct version". Having obsolete, incorrect geom hints set just technically looks wrong to me, plus also has obvious usability issues. I tend to vote for updating the hints.

Also wondering: What if (maybe in Wayland only) g-t completely removed the geometry hints in maximized/tiled states; and re-install when a regular size is restored? Would that help?

Or, in LEFT/RIGHT_TILED mode it could remove the vertical hints and keep (and maintain later) the horizontal one. Again, would that help in anything, or just further complicate our lives?

Simon, while we're at it, do you happen to see what's going on in bug 782863 comment 22, (2) and (3)? It's quite low prio, but probably also related.

(In reply to Egmont Koblinger from comment #26)
> I didn't (mean to) describe it as non-annoying in #10

Sure, I didn't intend to imply that. What I meant is: if we're trading off between suffering from one bug or another, the one I'd personally prefer to see fixed is the one fixed by 2f33a36 :-)

> Also wondering: What if (maybe in Wayland only) g-t completely removed the
> geometry hints in maximized/tiled states; and re-install when a regular size
> is restored?

Ah. I had thought that it did exactly that, but I now realise that I was wrong - it keeps the old, now-irrelevant hints. Yes, removing them might be a viable workaround for GTK+'s current behaviour.

> Or, in LEFT/RIGHT_TILED mode it could remove the vertical hints and keep
> (and maintain later) the horizontal one

We can't remove hints one-dimensionally, because GDK_HINT_RESIZE_INC covers both dimensions; but we could fake it by telling the compositor that we work in 16px increments (or whatever) in one dimension and 1px increments in the other.

(In reply to Simon McVittie from comment #25)
> (In reply to Egmont Koblinger from comment #20)
> > There are 2 things I still don't understand, see bug 751064. They're both
> > present regardless of the recent fix as well as the proposed followup.
> > 
> > - Maximize and unmaximize shrinks the terminal by 1x1.
> 
> I can reproduce this, and it's still an issue after applying the patches I
> proposed on Bug #789357.

It looks like this was Bug #777072, which is fixed in GTK+ git.

So hopefully GTK+ 3.22.25 will resolve all this. I'd recommend not reverting 2f33a36, since it makes life better for users of 3.22.{23,24} and will also make the eventual move to GTK+ 4 (where TILED might be removed altogether) go more smoothly.

(In reply to Egmont Koblinger from comment #27)
> Simon, while we're at it, do you happen to see what's going on in bug 782863
> comment 22, (2) and (3)? It's quite low prio, but probably also related.

Sorry, no idea how to solve those, unless the GTK+ changes happen to fix them.

(In reply to Simon McVittie from comment #29)
> (In reply to Simon McVittie from comment #25)
> > (In reply to Egmont Koblinger from comment #20)
> > > There are 2 things I still don't understand, see bug 751064. They're both
> > > present regardless of the recent fix as well as the proposed followup.
> > > 
> > > - Maximize and unmaximize shrinks the terminal by 1x1.
> > 
> > I can reproduce this, and it's still an issue after applying the patches I
> > proposed on Bug #789357.
> 
> It looks like this was Bug #777072, which is fixed in GTK+ git.

Unfortunately applying that patch hasn't solved this for me, so it's probably going to need more debugging.

Nice work getting these into GTK+ so quickly, thanks! :) I've patched my distro's GTK+ with 789357 & 777072, will continue testing on these.

With these fixes, half-maximized windows resize continuously using their side edge. That is, geom hints are totally ignored. (I'm actually surprisingly happy with this behavior, I'm unsure if grid-aligning horizontally would improve the experience.)

As such, the proposed fixup from comment 11 doesn't seem to introduce any regression, while it still fixes the case when you modify the font size and then unmaximize.

Gtk 3.22.25 will probably be released months before g-t 3.28, so I suggest that we just go ahead submit this followup (master only; without bothering with any GTK+ version or other conditionals).

(In reply to Egmont Koblinger from comment #32)
> With these fixes, half-maximized windows resize continuously using their
> side edge. That is, geom hints are totally ignored. (I'm actually
> surprisingly happy with this behavior, I'm unsure if grid-aligning
> horizontally would improve the experience.)

I agree - the character-cell-based resizing is something I want for ordinary floating windows (I missed it when it was broken), but I'm not sure how much of a benefit it would really be for tiled windows.

Christian, friendly ping, are you okay with the followup fix, as per my latest comment?

(In the mean time, GTK+ 3.22.25 is out now.)

(In reply to Egmont Koblinger from comment #34)
> Christian, friendly ping, are you okay with the followup fix, as per my
> latest comment?

Yes, I agree with that proposed change :-)

Oops, the fix mentioned in comment 11 doesn't seem to be perfect.

Without that change (that is, currently) resize increments aren't updated.

With that change, resize increment is properly updated but the constant addition to that isn't. That is, there's an additional padding on the right/bottom of the window and stays there even during resizes. A focus in/out eliminates it.

Looks like further work is required.

-- 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/gnome-terminal/-/issues/7774.