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

Previous Next

Full log

Message #150 received at 22000 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Vivek Dasmohapatra <vivek <at> etla.org>
Cc: 22000 <at> debbugs.gnu.org, David Engster <deng <at> randomsample.de>
Subject: Re: bug#22000: Patch addressing the menu-bar frame-resize interaction
Date: Tue, 16 Oct 2018 10:47:04 +0200

> 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

Previous Next

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