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

Previous Next

Full log

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

From: Vivek Dasmohapatra <vivek <at> etla.org>
To: martin rudalics <rudalics <at> gmx.at>
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: Thu, 19 Jul 2018 13:04:55 +0100 (BST)

[Message part 1 (text/plain, inline)]

> Can you point me to where gtk does that?

Backtrace (attached):

  gdk_frame_clock_paint_idle
  …
  → gtk_container_idle_sizer
  …
  → gtk_distribute_natural_allocation

Is the path, I think.

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

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

I'm not overly familiar with GTK myself - I'm just going by the docs
for gtk fixed. You may be correct: I'm not going to speculate further
or try to understand the underlying code, I'm just going to try it :)

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

>> You can turn scrollbars off in a scrolled window but unfortunately
>
> 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)?

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.

[gdb.txt (text/plain, attachment)]

Previous Next

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