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

From: Vivek Dasmohapatra <[email-masked]>
Date: Tue, 16 Oct 2018 02:19:00 +0100 (BST)

On Mon, 15 Oct 2018, martin rudalics wrote:

> - IIUC there's now no way for GTK < 3.16 to get the
>  'menu-bar-scrollbar' nil behavior.  No great deal but if you added
>  'forced-resize', then a user who does not like the large menu bar
>  can get that easily by using 'forced-resize' instead.  The default
>  for GTK < 3.16 would still be nil.

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

[cut]
> resize occurs only when a new menu bar shall be drawn.  Even now a
> user can alway truncate the menu bar by manually resizing the frame.
> This should be somehow mentioned in the text to avoid confusions.

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.

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

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)