bug#22000: Patch addressing the menu-bar frame-resize interaction

[Vivek Dasmohapatra]

On Mon, 16 Jul 2018, martin rudalics wrote:

> Making the menu bar a "scrolled window" appears like a rather gross
> hack to me and I think we should use it only as a last resort.  Can
> you tell what actually is different for a scrolled window in order to
> not trigger auto-resizing of its parent?

Literally what the scrolled window is for, from what I can tell: Make
a widget that otherwise makes hard demands of its parent for space
allocation into a scrollable one.

> I wonder why 'gtk_widget_set_size_request' does not handle this
> problem in the first place.  In 'create_menus' we do

> Is it possible that this gets reset later and/or another such call is
> needed when adding a new menu bar item?  After all, you can set a

Yes, I've been digging through the code a bit and it looks like the
menu bar recalculates everything when its contents change. In addition
there's an idle callback which occasionally asks the menu bar what it
thinks its size is.

I was hoping to be able to figure out if this was controllable from
user code by comparing with the tool bar, which does not seem to
display this symptom, but no luck so far.

> > It does make the menu bar taller than it was - This may be
> > addressable by using overlay scrollbars but there is currently
> > a bad focus interaction with those so the patch suppresses them
> > (overlay scrollbars) for now.
>
> How much taller does the menu bar get?  By the possible height of a
> horizontal scroll bar?

If you have overlay scrolling, no taller: If you don't, the height
of a scrollbar plus whatever spacing is defined for the scrollable
window by your gtk style (default: 3px).

> Thank you for working on this problem, martin

No problem, it's been annoying me for a few years now.