bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

>> What does your patch fix?
>
> There are no more oscillations between 1 and 2 on a GUI.
>
>> With a sufficiently small default font this will still return a value > 1.
>
> I use very small font, and the value is always 1.  Only when the tab bar
> is wrapped, the value becomes 2.

I merely referred to the tool bar whose height (especially on KDE) often
exceeds that of the default font by more than 2.  For the tab bar, try
to scale the tab-bar face by a factor of 2.0 or increase the height of
the `variable-pitch' face.

>> In either case, the height of the frame's inner rectangle plus those
>> of internal tab, tool and menu bar should equal the height of the
>> native rectangle in lines.  Did you check that?
>
> I don't know how to check this.

I doubt that we do it correctly now.  There's a check that tries to make
window sizes in lines and columns sum up correctly but there's no such
check for the frame decorations IIRC.

>> In my experience, there's no way to make column/line based variables and
>> functions always DTRT on a GUI.  Code should avoid them.
>
> Is it possible to avoid this when tab-bar-lines are calculated?

IIUC we have two ways to calculate tab-bar-lines in a logically correct
way: Have the display engine do it explicitly whenever it detects that a
tab-bar line is wrapped or implicitly by inspecting the glyph matrix
after the display engine is done with the tab bar.  A similar approach
can be used for the tool bar on Lucid/Motif/Windows and both tool and
menu bar on builds without toolkit support.

martin