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

From: martin rudalics <[email-masked]>
Date: Tue, 17 Jul 2018 09:48:47 +0200

> I have #ifdef'd the calls you mentioned with GTK_CHECK_VERSION guards.

Thank you.  It builds here now with GTK 3.4.2 and seems to have the
intended effect.

 > I also checked with one of the gnome/gtk devs and wrapping a
 > widget with strict ideas about its size is how you are supposed
 > to prevent its size from propagating:

I suppose the menu bar is a widget we never want to resize with GTK
and we want to get clipped pixelwise which means that the last
(rightmost here) entry may be partially visible but opens on a mouse
click and shows its submenus.  This contrasts with the tool bar where
we want a rightmost item either fit or be omitted, that is, never be
shown partially.

The major problem with your patch is that it completely breaks the
initial frame geometry at least here: The nominal (outer) height of
the initial frame (with emacs -Q) goes down from 749 to 731 pixels.
The height of the initial window goes down from 35 lines (630 pixels)
to 33 lines (595 pixels).

The height of the menu bar (calculated from the remaining components
because 'frame-geometry' sees no difference) seems to go up from 27 to
34 or 44 pixels which means an increase of 7 or 17 pixels.  I leave it
to your imagination what kind of uproar such behavior might provoke in
this our community.

So unless mine is very isolated, at the very least we would have to
make the behavior optional in order to address the concerns of all
users wrt implicit menu bar resizing and the size occupied by the menu
bar.  And we would have to fix the frame geometry calculations.

 > I suppose an alternative
 > would be some widget that doesn't resize or scroll at all,
 > but the basic approach would be the same.

There should be some.  I have no idea who is responsible for the tool
bar behavior but IIUC that should be the way to go for the menu bar
(with different clipping behavior, I suppose).

Could people who reported a similar behavior (see bugs 15700, 22898,
31626) test Vivek's patch?  I'm not sure whether they get this message
automatically, debbugs merging has always escaped my comprehension.
David, are you listening?

martin