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

[martin rudalics <rudalics@gmx.at>]

 > This patch attempts to address the menu-bar interaction with the
 > frame size: I've been using it locally for a short while now.

Thanks.  'gtk_widget_set_focus_on_click' is only available since GTK
3.20 and 'gtk_scrolled_window_set_overlay_scrolling' since 3.16 so
please condition your patch accordingly in order to allow compilation
with older versions (like mine).

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?

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

           wmenu = gtk_menu_bar_new ();
           /* Set width of menu bar to a small value so it doesn't enlarge
              a small initial frame size.  The width will be set to the
              width of the frame later on when it is added to a container.
              height -1: Natural height.  */
           gtk_widget_set_size_request (wmenu, 1, -1);

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
small initial width of a frame via 'default-frame-alist' so that the
menu bar is initially partially hidden/truncated.  Right?  So in
principle truncating should work but somehow breaks when we add items
to the menu bar.

Note that I can't really experiment with this because I don't get any
resizing here.

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

Thank you for working on this problem, martin