bug#23144: shrinking windows with gtk 3.20

[Matthias Clasen <matthias.clasen@gmail.com>]

On Sat, Apr 2, 2016 at 1:32 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 2 Apr 2016 13:27:25 -0400
>> From: Matthias Clasen <matthias.clasen@gmail.com>
>> Cc: martin rudalics <rudalics@gmx.at>, 23144@debbugs.gnu.org,
>>       Paul Eggert <eggert@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?

Well, it seems that nobody on your side remembers the reason for why
that particular xg_frame_resized call was added :-(

It is not that xg_frame_resized doesn't work anymore with GTK 3.22. It
just gets called at a time when the GdkWindow is not fully set up yet.
The reason that that happens now is due to a)  to some subtle changes
in the way GTK+ sets up windows initially and b) emacs poking directly
at X events like MapNotify.