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

[martin rudalics]

> 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