GNU bug report logs - #22000
25.0.50; Running dired changes frame width, gtk_distribute_natural_allocation throws assertion

Previous Next

Full log

Message #75 received at 22000 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Vivek Dasmohapatra <vivek <at> etla.org>
Cc: 22000 <at> debbugs.gnu.org, David Engster <deng <at> randomsample.de>
Subject: Re: 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.

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.