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

Previous Next

Full log

Message #144 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: Mon, 15 Oct 2018 20:23:10 +0200

> When in 'always or 'automatic mode, the menu bar will be in a scrolled
> window. The extra space cannot be properly ameliorated with CSS
> styling as this does not seem to work well. In the default mode,
> the scrolled window is not present - the menu bar is dynamically
> re-parented between the scrolled window (which is created on demand)
> and the emacs pane (vbox widget) when the menu bar scrolling mode
> is changed.
>
> At these GTK versions truncation does not work, so the menu bar
> frame size jitter big persists in the default mode.

Very good.  I can get my normal menu bar back with GTK 3.4.2.  But I'm
still inclined to ask you to do the following:

- Provide the forced frame resize behavior for GTK >= 3.16 as well.  I
  think the corresponding value of the menu-bar-scrollbar parameter
  should be something like 'forced-resize' in that case.

- 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.

+The behaviour of GTK menu bars when they would otherwise grow wider than

"behaviour" is "behavior" in the Emacs manual.

+the frame. Valid values are @code{always} to draw a scrollbar whether or

Please use two spaces after a sentence end in documentations.

+not it is required; @code{automatic} to draw one only when necessary; and
+@code{nil} (or any other value) for the default behaviour, which is to
+truncate the scrollbar if possible (GTK 3.16 and later). Prior to GTK 3.16
+the default behaviour is to force a frame resize: This is a GTK limitation.

This is too terse.  In particular "nil" also stands for not drawing a
scrollbar and that should stated.  And note that the forced frame
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.

Finally, I would provide a 'menu-bar-scrollbar-mode' that would add
the 'menu-bar-scrollbar' parameter automatically.  Please have a look
at how for example 'window-divider-mode' (which is off by default)
does that.  Then we could also add an entry in the "Show/Hide" entry
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, but
then we should mention that fact somewhere.

> [ Tested on gtk 3.22.11 and 3.4.2 ]

People are strongly urged to test this with their GTK builds.  At
least one or two feedbacks would be awfully welcome.  Maybe you could
also provide one large patch which includes all changes?

BTW, compiling with GTK 3.4.2 gives a spurious

../../src/gtkutil.c: In function ‘xg_update_frame_menubar’:
../../src/gtkutil.c:3609:22: warning: variable ‘sw’ set but not used [-Wunused-but-set-variable]

warning here.

Thanks, martin

Previous Next

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