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

[martin rudalics <rudalics@gmx.at>]

 > Backtrace (attached):
 >
 >    gdk_frame_clock_paint_idle
 >    …
 >    → gtk_container_idle_sizer
 >    …
 >    → gtk_distribute_natural_allocation
 >
 > Is the path, I think.

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
of adding an item to the menu bar must trigger it.

 >> I suppose the container respecting its wishes is that of the Emacs
 >> frame's window.  And if that container were a scrolled window, it
 >> would not auto-resize.  Do I reason correctly?
 >
 > Initially it's the box (vbox?) that the menubar is added to.
 > Not sure that's the top level widget.

If my reading of this is correct, resizing gets passed on from one
container to its parent until the top-level widget is reached.  Maybe
we could intercept that chain via gtk_container_set_resize_mode but I
don't know to which value.  'queued' doesn't sound very intriguing.

 >> Only the "virtual" container we'd add would have fixed size but this
 >> does not mean that it passes on the fixed size property to the menu
 >> bar's widget.  Inherently, this means that we would be cheating GTK
 >> another time.  Or am I wrong?
 >
 > IIUC you are right - that's how you're supposed to do it - I just don't
 > know if there's a non-deprecated widget that does what we want.
 >
 > Worst case scenario: If I grab the scrolled window class and mutilate it

Above I meant using the gtk fixed window class for the container, not
the scrolled window one.

 > till it does what we want, would you consider emacs carrying that widget
 > class in its code? It shouldn't change any of the build dependencies.
 >
 > NOTE: FWIW even the hbox and vbox we are using are deprecated and have
 > been for a while, so this whole area of code is going to need to be converted over to gtk grid at some point anyway.

I never started counting the areas of Emacs code that would require
similar treatment.

 > You can suppress the scrollbars independently, but that's what restores
 > the unwanted resizing behaviour in that direction: Suppress the vertical
 > scrollbar and suddenly vertical size requests are honoured, suppress
 > the horizontal and suddenly the menu bar can force the frame size again.

I made the silly assumption that turning off horizontal bars would
still inhibit horizontal resizing.  It must be the other way round.

martin