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

From: martin rudalics <[email-masked]>
Date: Fri, 19 Oct 2018 19:57:38 +0200

> 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