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

[Vivek Dasmohapatra]

> The patchset still doesn't apply to master since master has evolved
> differently.  I get:

Where exactly (commit id) are you applying the patch?

[cut]

>  GtkScrolledWindow *sw;
>
> has been removed from the former and the latter is now

GtkScrolledWindow is introduced by the patch series - I'm confused:
Which patch series did you try and where?

> Here patches 0001 and 0002 fix the resize problem but I get a too large
> menu bar which makes GTK builds pretty unusable.  Didn't we agree that
> you make the fix optional?  That is, one option value (say 'truncate')

I can make truncation the default behaviour (in fact it is),
the problem is the presence of the scrolledwindow which is necessary
for the fix introduces extra padding. I'm not sure there's a way to fix 
that (well, I guess there is but it's a little tricky as it means the
scrolledwindow has to appear and disappear entirely from the widget 
hierarchy).

I might be able to fix it with a style change, if I can defeat the gtk3 docs
and figure out if/how to set a style property on a widget.

> for users who want the resize problem get fixed and who are willing to
> pay for that with a higher menu bar.  And one option value (say
> 'resize') for users who can live with the resizing problem but care more
> about the height of the menu bar.


> Patches 0003, 0004 and 0005 make the menu bar invisible at start (with
> emacs -Q) and don't allow to bring it back via M-x: menu-bar-mode.  I
> can get it back with my customized Emacs, though.  Any ideas (this is
> GTK version 3.4.2)?

That's pretty old... even on oldstable I have 3.14. I can try and find a 
system with that version of GTK, wondering if it's a GTK bug.