[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: martin rudalics
Subject: bug#22000: Patch addressing the menu-bar frame-resize interaction
Date: Fri, 20 Jul 2018 10:14:47 +0200

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]