Subject: Re: bug#23144: shrinking windows with gtk 3.20

From: Matthias Clasen <[email-masked]>
Date: Sat, 2 Apr 2016 19:20:41 -0400

On Sat, Apr 2, 2016 at 1:32 PM, Eli Zaretskii <[email-masked]> wrote:
>> Date: Sat, 2 Apr 2016 13:27:25 -0400
>> From: Matthias Clasen <[email-masked]>
>> Cc: martin rudalics <[email-masked]>, [email-masked],
>>       Paul Eggert <[email-masked]>
>>
>> > 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.