GNU bug report logs -
#23144
shrinking windows with gtk 3.20
Previous Next
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):
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.