bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Vivek Dasmohapatra
Subject: bug#22000: Patch addressing the menu-bar frame-resize interaction
Date: Tue, 16 Oct 2018 02:19:00 +0100 (BST)
User-agent: Alpine 2.02 (DEB 1266 2009-07-14)

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)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]