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

[martin rudalics]

>> suppose we used a non-scrolled container window to put the menu bar
>> in, get its size before updating the menu bar, update the menu bar and
>> make a gtk_widget_set_size request for that container window to
>> restore its previous size.  Would that fail and why?
>
> Depends on the behaviour of the container. The menu bar gets poked
> to emit its size from time to time by an internal gtk callback

Can you point me to where gtk does that?

> so if the container respects its wishes it will pop back to the larger
> size semi-predictably (this behaviour can occasionally be seen in
> the currently released emacs as that's how the hbox behaves).

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?

> So we'd need a container that didn't grant such space requests.
> gtk fixed is close, but from its documentation has other
> limitations we don't want (no RTL support).

I'm probably too silly to understand the semantics of containers: The
menu bar widget's size is not fixed so its RTL behavior (and the
font/translation issues gtkfixed talks about) would not be affected.
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?

> You can turn scrollbars off in a scrolled window but unfortunately
> this results in the scrolled window responding to size allocation
> requests from its child.

This is incoherent, at least.  Could we suppress horizontal scroll
bars separately in a scrolled window (because I think that these are
responsible for the height increase of the menu bar)?

martin