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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Matthias Clasen <matthias.clasen <at> gmail.com>
Cc: rudalics <at> gmx.at, eggert <at> cs.ucla.edu, 23144 <at> debbugs.gnu.org
Subject: bug#23144: shrinking windows with gtk 3.20
Date: Sat, 02 Apr 2016 20:32:46 +0300

> Date: Sat, 2 Apr 2016 13:27:25 -0400
> From: Matthias Clasen <matthias.clasen <at> gmail.com>
> Cc: martin rudalics <rudalics <at> gmx.at>, 23144 <at> debbugs.gnu.org, 
> 	Paul Eggert <eggert <at> cs.ucla.edu>
> 
> > Do we understand the effect of this?  It effectively makes the
> > xg_frame_resized call a no-op, but I very much doubt that this call
> > was added there with no good reason.  Does the history of this
> > addition, including any related discussions, teach us something about
> > the reason?
> 
> Yes, this is what I would have suggested as alternative patch for
> emacs 25. It only disregards the return value of
> gdk_window_get_geometry if it is still the initial value of 1,1 -
> thats clearly not a useful size for an emacs window...

Ignoring the 1x1 dimensions is a no-brainer.  What bothers me is
something else entirely: that call to xg_frame_resized was most
probably added there for a reason; if xg_frame_resized no longer works
with GTK 3.22 and later as it did before, the question is what, if
anything, else do we lose with the new behavior?

Could you perhaps describe what that call does in older versions of
GTK, and why it worked before, but not anymore?

Thanks.

Previous Next

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