GNU bug report logs - #23144
shrinking windows with gtk 3.20

Previous Next

Package: emacs;

Reported by: Matthias Clasen <matthias.clasen <at> gmail.com>

Date: Tue, 29 Mar 2016 14:20:01 UTC

Severity: important

Merged with 24707

Found in version 25.1

Fixed in version 26.1

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


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

From: Matthias Clasen <matthias.clasen <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: shrinking windows with gtk 3.20
Date: Mon, 28 Mar 2016 16:52:47 -0400
We've observed that after

https://git.gnome.org/browse/gtk+/commit/?id=67ab00e01ec06d7b05a82c3d80b235ac6c4abfd2

emacs windows shrink to a small height, after initially appearing with
the expected size. For that reason, I have reverted to commit in the
stable gtk 3.20 branch.

But after looking a bit closer, I find that what emacs does is really
unsupportable: It handles X events behind GTK+'s back, and upon seeing
a map notify, it calls xg_frame_resized with -1, -1 for width and
height, which makes it call gdk_window_get_geometry to obtain the
current size. But at that point (before GTK+ has handled the map
notify), the function still returns the initial values of 1, 1, which
then leads eventually to a call of gtk_window_resize() with the small
height that we're seeing the window shrink to.

Therefore, I will bring back the reverted change in GTK+ master.

Possible workarounds/fixes in the emacs code:

1) Recognize when gdk_window_get_geometry returns the initial size
(1,1) and silently return as if the window was unmapped.

2) Just drop the xg_frame_resized call on MapNotify. Omitting it
doesn't have any noticeable negative consequences.




This bug report was last modified 6 years and 223 days ago.

Previous Next


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