Revise geometry hints

[Egmont Koblinger]

Followup of bug 1498833:

Current gtk3 branch is not perfect, not even with a single window, single tab, single pane (that is, single terminal).

Launch a fullscreen app, e.g. mc, to see if the window size is not properly aligned. If you slowly drag the corner, everything's fine. If you quickly drag it, and suddenly shrink the window from around 200x50 to around 60x20 or so, an additional undesired padding appears. (I have no clue how this could happen and I'm not planning to debug it.)

If you open a second tab, the geometry could be hinted to grid-aligned values taking the notebook widget into account (as e.g. in gnome-terminal), but it is not.

As you start using panes (and probably you do, that's the killer feature of terminator!), suddenly the whole concept no longer makes sense. Even with just two panes, each resize increment is divided equally: both tabs get an additional half character cell, what would they use half a cel for?

With three panes (e.g. Ctrl+Shift+O and then Ctrl+Shift+E: you'll have a top (wide) terminal, a bottom left, and a bottom right) geometry hints can either get the width of the upper terminal or the width of the two bottom terminals correct, but not all of them at the same time. Unless right padding + scrollbar width + separator width + left padding happens to be exactly as wide as a charcell.

And what should happen if different panes have different font sizes?

The current way of geometry hinting is only feasible when panes are not used (which is not a typical use case for terminator at all; in that case probably the user would stick to gnome-terminal), and even then it's buggy. When panes are used, there's theoretically just no correct way of defining the hints.

Hence I'm all for removing it... or:

What about a strictly grid-aligned layout, as an option? Pretty much the way tmux looks like.

All panes of a tab forced to the same font, horizontal separator forced to be cell_height - top_padding - bottom_padding tall, vertical separator forced to be cell_width - left_padding - right_padding - scrollbar_width wide. (Or if these would be negative/zero then increment by yet another few times cell_height or cell_width as necessary. The current handle_size config option could define the minimum required width.) Dragging these panes would also make bigger jumps, always at aligned positions.

When widening a window of let's say two adjacent panes, they wouldn't both widen by half cell at a time, alternatingly one or the other would become wider by an entire cell. This is probably the simplest to implement by having an internal exact desired position (probably a float so that with 3 adjacent panes each could increase by 1/3 at a time), and round that to get the actual position (but always do the math with the unrounded value).

What do you think?

[Stephen Boddy (stephen-j-boddy)]

> What do you think?

I think I hate window geometry hinting, and I'm also in favour of removing it, because it causes more than enough grief on it's own and as you say it can be inconsistent. Not sure if that should be done now or left to another big release. It's off by default now, and people have to actively turn it on.