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

Previous Next

Package: emacs;

Reported by: David Engster <deng <at> randomsample.de>

Date: Mon, 23 Nov 2015 20:56:02 UTC

Severity: normal

Merged with 15700, 18270, 22898, 25313, 31626

Found in versions 24.3, 24.5, 25.0.50

Full log


View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Vivek Dasmohapatra <vivek <at> etla.org>, 22000 <at> debbugs.gnu.org
Subject: bug#22000: Patch addressing the menu-bar frame-resize interaction
Date: Mon, 16 Jul 2018 09:28:17 +0200
> This patch attempts to address the menu-bar interaction with the
> frame size: I've been using it locally for a short while now.

Thanks.  'gtk_widget_set_focus_on_click' is only available since GTK
3.20 and 'gtk_scrolled_window_set_overlay_scrolling' since 3.16 so
please condition your patch accordingly in order to allow compilation
with older versions (like mine).

Making the menu bar a "scrolled window" appears like a rather gross
hack to me and I think we should use it only as a last resort.  Can
you tell what actually is different for a scrolled window in order to
not trigger auto-resizing of its parent?

I wonder why 'gtk_widget_set_size_request' does not handle this
problem in the first place.  In 'create_menus' we do

          wmenu = gtk_menu_bar_new ();
          /* Set width of menu bar to a small value so it doesn't enlarge
             a small initial frame size.  The width will be set to the
             width of the frame later on when it is added to a container.
             height -1: Natural height.  */
          gtk_widget_set_size_request (wmenu, 1, -1);

Is it possible that this gets reset later and/or another such call is
needed when adding a new menu bar item?  After all, you can set a
small initial width of a frame via 'default-frame-alist' so that the
menu bar is initially partially hidden/truncated.  Right?  So in
principle truncating should work but somehow breaks when we add items
to the menu bar.

Note that I can't really experiment with this because I don't get any
resizing here.

> It does make the menu bar taller than it was - This may be
> addressable by using overlay scrollbars but there is currently
> a bad focus interaction with those so the patch suppresses them
> (overlay scrollbars) for now.

How much taller does the menu bar get?  By the possible height of a
horizontal scroll bar?

Thank you for working on this problem, martin




This bug report was last modified 5 years and 266 days ago.

Previous Next


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