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

[martin rudalics]

> I've applied the patches in
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2018-10/msg00514.html
> to current master and everything seems to be working as it should.  This
> is with GTK+ 3.22.30 and Openbox using several GNOME libraries; I don't
> have a complete GNOME DE but I may be able to try with KDE over the
> weekend.

Thank you very much for testing.

> There are a couple of visual oddities: when the `menu-bar-scrollbar'
> frame parameter has the value nil or `forced-resize' (or when the item
> "Menu Bar Scroll/Truncate" of the Options->Show/Hide menu is set to
> "Truncate" or "Resize Frame"), then there is no thin dividing line
> between the menu bar and the tool bar (in contrast to Emacs built
> without this patchset), and in addition, when a menu bar menu is open,
> the dividing lines in the menu are rather thick; but when the
> `menu-bar-scrollbar' frame parameter has the value `automatic', the thin
> dividing line between the menu bar and the tool bar is displayed (and
> the menu bar itself is noticeably thicker than in Emacs built without
> this patchset), and the dividing lines in an open menu are thinner,
> though not as thin as the line between the menu and tool bars (in Emacs
> built without this patchset the menu dividers are just as thin as the
> the divider between the menu and tool bars); with the parameter value
> `always' the scroll bar replaces the dividing line between the menu and
> tool bars, and the menu dividers have the same thickness as with the
> `automatic' setting.

I see none of these phenomenas with GTK 3.4.2 under xfce4.  Just that
with 'always' and 'automatic' the menu bar has three times the height
of 'forced-resize' and has a 3D look absent with the latter.  But GTK
3.4.2 is not really the target of Vivek's patch.

martin