bug#46827: Broken initial size of GTK3 frame

[Juri Linkov <juri@linkov.net>]

>> Accoring to window-total-height, the currently used rounding
>> in x_change_tab_bar_height corresponds to 'ceiling':
>>
>>        return make_fixnum (EQ (round, Qceiling)
>> 			  ? ((w->pixel_height + unit - 1) /unit)
>>
>> On a TTY where the frame line height is 1, this gives the correct result.
>> But not on a GUI where the frame line height is measured in pixels.
>>
>> When the argument 'round' of window-total-height is 'floor',
>> it uses the formula without subtracting 1 that works on a GUI too:
>>
>> 			  : (w->pixel_height / unit));
>>
>> This patch fixes this in x_change_tab_bar_height.  Do you think the same
>> fix should be applied to x_change_tool_bar_height as well?
>
> 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.

> 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.

> 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?