[Top][All Lists]

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

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

From: martin rudalics
Subject: 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

reply via email to

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