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

Previous Next

Full log

Message #81 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: Fri, 20 Jul 2018 14:34:12 +0200

>> Why doesn't this process kick in after I shrink the frame width
>> manually such that the menu bar is cropped?  Something in the course
>
> It does for me. If I try to shrink the frame manually it either
> pops back immediately or after a brief pause (occasionally
> a long pause, but it usually "wakes up" when I interact with the UI).

I see.  Making the default emacs -Q frame narrow enough so the Help
menu entry is not showing, maximizing and demaximizing that frame
shows the Help menu again.

> Oh, sure - I wasn't clear - I tried adding a gtk fixed and it behaves
> for our purposes the same way as an hbox - it honours resize requests,
> despite its name. The fixed appears to refer to layout (positioning)
> only, not size.

Then I'm at my wits' end.  Please devise a new option like, for
example, 'gtk-menu-bar-no-auto-resize' and condition execution of your
code on the value of that variable.  And please explain the trade-offs
in the doc-string of that option and that the option may be removed in
the future.  Otherwise, people might claim that they do like the
auto-resizing in the unlikely case that we do find a better solution.
And we eventually have to document this in the manuals.

Thanks again for all the work, martin

Previous Next

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