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

Previous Next

Package: emacs;

Reported by: David Engster <deng <at> randomsample.de>

Date: Mon, 23 Nov 2015 20:56:02 UTC

Severity: normal

Merged with 15700, 18270, 22898, 25313, 31626

Found in versions 24.3, 24.5, 25.0.50

Full log


View this message in rfc822 format

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: bug#22000: Patch addressing the menu-bar frame-resize interaction
Date: Thu, 19 Jul 2018 10:19:32 +0200
>> 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




This bug report was last modified 5 years and 266 days ago.

Previous Next


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