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

[martin rudalics <rudalics@gmx.at>]

 > Assuming nil behaviour = menu bar is truncated when too wide but
 > has no scrollbar and no extra padding - GTK < 3.16 can't do this
 > without either implementing a custom widget or providing the
 > equivalent of GTK_POLICY_EXTERNAL.
 >
 > 3.16+:
 > always        - scrollbar always present, menu bar would be vertically
 >                  padded but we compress it with CSS
 > automatic     - similar, but scrollbar disappears when not required
 > forced-resize - no scrollbar and no padding. frame will resize
 >                  semi-predictably when the menu bar's natural size
 >                  exceeds that of the frame.
 > nil           - no scrollbar, menu would be vertically padded but
 >                  we compress it with CSS. menu bar is truncated
 >                  if it tries to extend past the frame edge.
 >
 > 3.16-:
 > always        - scrollbar always present, menu bar is vertically
 >                  padded. does not appear to bepossible to fix
 >                  this with CSS.
 > automatic     - similar, but scrollbar disappears when not required
 > forced-resize - no scrollbar and no padding. frame will resize
 >                  semi-predictably when the menu bar's natural size
 >                  exceeds that of the frame.
 > nil           - identical to forced-resize for these GTK versions

Good.  We could for the 3.16- nil case do what you did earlier with
the extra padding but I think that having this as default would harm
more than do any good.  So let's stick to this your proposal - it's
the most sane approach I can think of at the moment.

 > To clarify - a user can _try_ to manually resize the frame but sooner
 > or later (usually sooner) the gdk timer fires and gtk notices that
 > the menu bar wants more space and resizes the frame. Depending on
 > your exact GTK version and the phase of the moon you _may_ be able
 > to dodge this forced resize but you cannot reliably do so.

Yes.  I forgot about this timer issue.

 >> of the Options menu.  Provided we can add/remove a menu bar scrollbar
 >> dynamically to/from an existing frame.  No great harm if we can't
 >
 > We can, I've been testing this to make sure it works.

Fine.

 > Currently working on updating the patches to address these points (and the others to which I have not replied specifically here) - will probably
 > send an updated series tomorrow (2018-10-16)

We'll then have to discuss with Eli whether to apply this to Emacs
26.2 or to master.

Thanks, martin