GNU bug report logs - #22000
25.0.50; Running dired changes frame width, gtk_distribute_natural_allocation throws assertion

Previous Next

Full log

View this message in rfc822 format

From: Vivek Dasmohapatra <vivek <at> etla.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 22000 <at> debbugs.gnu.org, David Engster <deng <at> randomsample.de>
Subject: bug#22000: Patch addressing the menu-bar frame-resize interaction
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)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.