bug#23144: shrinking windows with gtk 3.20

bug#23144: shrinking windows with gtk 3.20

[Matthias Clasen]

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.

bug#23144: shrinking windows with gtk 3.20

[martin rudalics]

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

Could you please provide a patch for the latter?  Less for the change
itself but more so for getting the right comment motivating it.

But we should decide first whether to make the change on the release
version.  Eli, John?

Thanks, martin

bug#23144: shrinking windows with gtk 3.20

[Eli Zaretskii]

> Date: Tue, 29 Mar 2016 17:18:21 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
>  > 2) Just drop the xg_frame_resized call on MapNotify. Omitting it
>  > doesn't have any noticeable negative consequences.
> 
> Could you please provide a patch for the latter?  Less for the change
> itself but more so for getting the right comment motivating it.
> 
> But we should decide first whether to make the change on the release
> version.  Eli, John?

I don't know anything about GTK vs Emacs operation, except that Jan
generally knew what he was doing.  Too bad he's not around anymore to
respond to this issue, I fear we are going to get bugs elsewhere.

bug#23144: shrinking windows with gtk 3.20

[martin rudalics]

 > I don't know anything about GTK vs Emacs operation, except that Jan
 > generally knew what he was doing.  Too bad he's not around anymore to
 > respond to this issue, I fear we are going to get bugs elsewhere.

That's why I hope that Matthias could help us with this issue.  I don't
even understand why Jan called xg_frame_resized here.  That is, I
understand the technical reason for the -1 arguments, but I don't
understand why he considered the call itself necessary.  The ChangeLog
entry contains no motivations.

martin

bug#23144: shrinking windows with gtk 3.20

[John Wiegley]

>>>>> martin rudalics <rudalics@gmx.at> writes:

> But we should decide first whether to make the change on the release
> version. Eli, John?

If it's a serious bug, maybe; it depends on the scope of the change and the
number of users it affects. 25.1 _will_ ship with some bugs, we can't avoid
that; so at this point we're trying as much as possible only to improve the
stability of our pretests.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

bug#23144: shrinking windows with gtk 3.20

[martin rudalics]

 > If it's a serious bug, maybe; it depends on the scope of the change and the
 > number of users it affects. 25.1 _will_ ship with some bugs, we can't avoid
 > that; so at this point we're trying as much as possible only to improve the
 > stability of our pretests.

It's not about the severity of the bug; it's merely about how to react.

I think we have two possibilites to deal with this issue: Ignore it or
implement a fix.  If we ignore it, we might run into difficulties later
when gtk developers eventually decide to apply the change in question or
we find a case where our code does not DTRT anyway.  As Eli already
mentioned, after Jan's departure nobody here is in grade to maintain the
gtk interface reliably.

If we try to fix it, we could possibly rely on Matthias to give us clues
on how to proceed and what to do if the fix causes problems.  If the fix
goes into master, there are chances that any such problems will pass by
unnoticed for some time since currently most people here seem to use the
release version.

martin

bug#23144: shrinking windows with gtk 3.20

[Eli Zaretskii]

> Date: Fri, 01 Apr 2016 09:48:50 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: 23144@debbugs.gnu.org, Matthias Clasen <matthias.clasen@gmail.com>
> 
> I think we have two possibilites to deal with this issue: Ignore it or
> implement a fix.  If we ignore it, we might run into difficulties later
> when gtk developers eventually decide to apply the change in question or
> we find a case where our code does not DTRT anyway.  As Eli already
> mentioned, after Jan's departure nobody here is in grade to maintain the
> gtk interface reliably.
> 
> If we try to fix it, we could possibly rely on Matthias to give us clues
> on how to proceed and what to do if the fix causes problems.  If the fix
> goes into master, there are chances that any such problems will pass by
> unnoticed for some time since currently most people here seem to use the
> release version.

How about the following course:

 . On master, accept what Matthias suggests and deal with bug reports
   if and when they come.

 . On the release branch, provide some safe workaround, triggered by
   an option users could set if they encounter this problem with a
   future GTK version.  This assumes such a safe workaround is
   possible, of course; I thought along the lines of the user
   specifying the initial size explicitly in some way.

Would that work?

bug#23144: shrinking windows with gtk 3.20

[Paul Eggert]

> How about the following course:
>
>   . On master, accept what Matthias suggests and deal with bug reports
>     if and when they come.

Sounds good, and I did that.

>   . On the release branch, provide some safe workaround, triggered by
>     an option users could set if they encounter this problem with a
>     future GTK version.  This assumes such a safe workaround is
>     possible, of course; I thought along the lines of the user
>     specifying the initial size explicitly in some way.
>

Another possibility is to ask builders not to combine GTK+4 (or will 
this be GTK+ 3.22? it's not clear), whenever it comes out, with Emacs 25 
whenever it comes out; and to instead stick with GTK+ 3.20 or earlier 
when building Emacs 25. If that's a reasonable request then the problem 
goes away.

bug#23144: shrinking windows with gtk 3.20

[Eli Zaretskii]

> Cc: 23144@debbugs.gnu.org, Matthias Clasen <matthias.clasen@gmail.com>
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 1 Apr 2016 17:03:39 -0700
> 
> >   . On the release branch, provide some safe workaround, triggered by
> >     an option users could set if they encounter this problem with a
> >     future GTK version.  This assumes such a safe workaround is
> >     possible, of course; I thought along the lines of the user
> >     specifying the initial size explicitly in some way.
> >
> 
> Another possibility is to ask builders not to combine GTK+4 (or will 
> this be GTK+ 3.22? it's not clear), whenever it comes out, with Emacs 25 
> whenever it comes out; and to instead stick with GTK+ 3.20 or earlier 
> when building Emacs 25. If that's a reasonable request then the problem 
> goes away.

Such a request, if we agree to that, should be in the form of
configure rejecting GTK+4.  I don't believe in our ability to reach
all of the package maintainers and convince them.

But if we can find a reasonable fire escape without rejecting new
versions of GTK, I think it would be a better alternative.

bug#23144: shrinking windows with gtk 3.20

[Matthias Clasen]

On Sat, Apr 2, 2016 at 3:01 AM, Eli Zaretskii <eliz@gnu.org> wrote:

>>
>> Another possibility is to ask builders not to combine GTK+4 (or will
>> this be GTK+ 3.22? it's not clear), whenever it comes out, with Emacs 25
>> whenever it comes out; and to instead stick with GTK+ 3.20 or earlier
>> when building Emacs 25. If that's a reasonable request then the problem
>> goes away.
>
> Such a request, if we agree to that, should be in the form of
> configure rejecting GTK+4.  I don't believe in our ability to reach
> all of the package maintainers and convince them.
>
> But if we can find a reasonable fire escape without rejecting new
> versions of GTK, I think it would be a better alternative.

Thanks for the fix on master, Paul. I can confirm that it works fine
with GTK+ master.

We're not talking about GTK4 here. GTK+ master will be released as
3.22 in the fall. But I am getting reports about various other
problems that are caused by the reversal on the gtk-3-20 branch, so I
may have to put the problematic (for emacs) back in the 3.20 branch.

If you consider the patch too risky to put in the emacs 25 branch at
this point, an alternative might be to put a release note to inform
distributors about this incompatibility and point them at the commit,
so they can pick it up if they want to ship emacs 25 with gtk 3.20.

bug#23144: shrinking windows with gtk 3.20

[Eli Zaretskii]

> Date: Sat, 2 Apr 2016 11:19:00 -0400
> From: Matthias Clasen <matthias.clasen@gmail.com>
> Cc: Paul Eggert <eggert@cs.ucla.edu>, 23144@debbugs.gnu.org
> 
> If you consider the patch too risky to put in the emacs 25 branch at
> this point, an alternative might be to put a release note to inform
> distributors about this incompatibility and point them at the commit,
> so they can pick it up if they want to ship emacs 25 with gtk 3.20.

We would prefer to not include the change in Emacs 25.1 (that will be
released from the emacs-25 branch), and instead have some workaround
there that will be activated by the end-users, if and when they see
problems related to this.  Can you propose such a workaround?
Something like a call to xg_frame_resized with some reasonable
dimensions, for example?

TIA

bug#23144: shrinking windows with gtk 3.20

[martin rudalics]

 > We would prefer to not include the change in Emacs 25.1 (that will be
 > released from the emacs-25 branch), and instead have some workaround
 > there that will be activated by the end-users, if and when they see
 > problems related to this.  Can you propose such a workaround?
 > Something like a call to xg_frame_resized with some reasonable
 > dimensions, for example?

In emacs-25 either use something like

#if !GTK_CHECK_VERSION (3, 20, 0))
           xg_frame_resized (f, -1, -1);
#endif

or, as Matthias proposed, in xg_frame_resized write

   if (pixelwidth == -1 && pixelheight == -1)
     {
       if (FRAME_GTK_WIDGET (f) && gtk_widget_get_mapped (FRAME_GTK_WIDGET (f)))
	{
	  gdk_window_get_geometry (gtk_widget_get_window (FRAME_GTK_WIDGET (f)),
				   0, 0, &pixelwidth, &pixelheight);
	  if (pixelwidth <= 1 || pixelheight <= 1)
	    return;
	}
       else
	return;
     }

martin

bug#23144: shrinking windows with gtk 3.20

[Eli Zaretskii]

> Date: Sat, 02 Apr 2016 18:06:16 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 23144@debbugs.gnu.org, eggert@cs.ucla.edu
> 
> In emacs-25 either use something like
> 
> #if !GTK_CHECK_VERSION (3, 20, 0))
>            xg_frame_resized (f, -1, -1);
> #endif

I hope we do that on master.  If not, we should.  There's no reason
not to continue calling xg_frame_resized with older versions of GTK,
as it works there.

I'm wary of doing this in Emacs 25.1.

> or, as Matthias proposed, in xg_frame_resized write
> 
>    if (pixelwidth == -1 && pixelheight == -1)
>      {
>        if (FRAME_GTK_WIDGET (f) && gtk_widget_get_mapped (FRAME_GTK_WIDGET (f)))
> 	{
> 	  gdk_window_get_geometry (gtk_widget_get_window (FRAME_GTK_WIDGET (f)),
> 				   0, 0, &pixelwidth, &pixelheight);
> 	  if (pixelwidth <= 1 || pixelheight <= 1)
> 	    return;
> 	}
>        else
> 	return;
>      }

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?

Thanks.

bug#23144: shrinking windows with gtk 3.20

[Matthias Clasen]

On Sat, Apr 2, 2016 at 12:28 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 02 Apr 2016 18:06:16 +0200
>> From: martin rudalics <rudalics@gmx.at>
>> CC: 23144@debbugs.gnu.org, eggert@cs.ucla.edu
>>
>> In emacs-25 either use something like
>>
>> #if !GTK_CHECK_VERSION (3, 20, 0))
>>            xg_frame_resized (f, -1, -1);
>> #endif
>
> I hope we do that on master.  If not, we should.  There's no reason
> not to continue calling xg_frame_resized with older versions of GTK,
> as it works there.
>
> I'm wary of doing this in Emacs 25.1.
>
>> or, as Matthias proposed, in xg_frame_resized write
>>
>>    if (pixelwidth == -1 && pixelheight == -1)
>>      {
>>        if (FRAME_GTK_WIDGET (f) && gtk_widget_get_mapped (FRAME_GTK_WIDGET (f)))
>>       {
>>         gdk_window_get_geometry (gtk_widget_get_window (FRAME_GTK_WIDGET (f)),
>>                                  0, 0, &pixelwidth, &pixelheight);
>>         if (pixelwidth <= 1 || pixelheight <= 1)
>>           return;
>>       }
>>        else
>>       return;
>>      }
>
> 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...

bug#23144: shrinking windows with gtk 3.20

[Eli Zaretskii]

> 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?

Thanks.

bug#23144: shrinking windows with gtk 3.20

[Matthias Clasen]

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.

bug#23144: shrinking windows with gtk 3.20

[Eli Zaretskii]

> Date: Sat, 2 Apr 2016 19:20:41 -0400
> From: Matthias Clasen <matthias.clasen@gmail.com>
> Cc: martin rudalics <rudalics@gmx.at>, 23144@debbugs.gnu.org, 
> 	Paul Eggert <eggert@cs.ucla.edu>
> 
> > 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 :-(

The developer who was our expert on GTK has stepped down.  That can
happen to any project, I think.

> 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.

Thanks.  Is there a way of knowing when the GdkWindow is fully set up?

bug#23144: shrinking windows with gtk 3.20

[Paul Eggert]

As I understand it, the current version (3.20.4) of Gtk+ incorporates the
cleanup patch
<https://git.gnome.org/browse/gtk+/commit/?id=67ab00e01ec06d7b05a82c3d80b235ac6c4abfd2>
that causes the problem with Emacs 25 that Matthias noted in
<http://bugs.gnu.org/23144>. I haven't tested this, though.

As the bug was fixed in the Emacs master branch early last month
<http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=afc9e6542aa6f2d0d7986db3d8c2cb654e107443>,
and nobody has seemed to complain, I'm becoming more inclined to cherry-pick the
fix into the emacs-25 branch. I'm by no means an expert in this area, but it
does seem to be a looming problem if we continue to do nothing.

bug#23144: shrinking windows with gtk 3.20

[martin rudalics]

 > As the bug was fixed in the Emacs master branch early last month
 > <http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=afc9e6542aa6f2d0d7986db3d8c2cb654e107443>,
 > and nobody has seemed to complain,

I'm afraid that most people are using the release version currently.

 > I'm becoming more inclined to cherry-pick the
 > fix into the emacs-25 branch. I'm by no means an expert in this area, but it
 > does seem to be a looming problem if we continue to do nothing.

Indeed.

martin

bug#23144: shrinking windows with gtk 3.20

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: Matthias Clasen <matthias.clasen@gmail.com>, Eli Zaretskii
>  <eliz@gnu.org>, rudalics@gmx.at
> Date: Sun, 15 May 2016 23:53:07 -0700
> 
> As I understand it, the current version (3.20.4) of Gtk+ incorporates the
> cleanup patch
> <https://git.gnome.org/browse/gtk+/commit/?id=67ab00e01ec06d7b05a82c3d80b235ac6c4abfd2>
> that causes the problem with Emacs 25 that Matthias noted in
> <http://bugs.gnu.org/23144>. I haven't tested this, though.
> 
> As the bug was fixed in the Emacs master branch early last month
> <http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=afc9e6542aa6f2d0d7986db3d8c2cb654e107443>,
> and nobody has seemed to complain, I'm becoming more inclined to cherry-pick the
> fix into the emacs-25 branch.

Or we could reject GTK+ 3.20.4 and later for Emacs 25.1 at configure
time.  I have no idea which alternative is better.  (And no, lack of
complaints doesn't seem to be a good enough indicator: look at the
number of serious problems with emacs-25 which are only now starting
to be reported.  It sounds like only pretest releases are used widely
enough to catch some configurations.)

> I'm by no means an expert in this area, but it does seem to be a
> looming problem if we continue to do nothing.

We don't have experts available, it seems.  We have no idea what we
are doing with these changes.  I hoped the GTK people will be
motivated enough to help us out, but it doesn't look like it's
happening, sigh.

bug#23144: shrinking windows with gtk 3.20

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

On 05/16/2016 08:53 AM, Eli Zaretskii wrote:
> we could reject GTK+ 3.20.4 and later for Emacs 25.1 at configure
> time.

On further investigation of the Gtk+ source, it appears that the Gtk+ 
change went in at release 3.20.3. Since it seems clear that Emacs has 
serious problems in 3.20.3 or later because of the call to 
xg_frame_resized, I installed the attached patch and am boldly closing 
the bug report. Quite possibly there is a better way to fix the bug but 
I hope this is good enough to get by.


[-- Attachment #2: 0001-Avoid-shrinking-windows-with-Gtk-3.20.3.patch --]
[-- Type: application/x-patch, Size: 1095 bytes --]

bug#23144: shrinking windows with gtk 3.20

[Ken Brown]

Yaakov Selkowitz has pointed out that the fix for this bug on the 
emacs-25 branch should have used the function gtk_check_version rather 
than the macro GTK_CHECK_VERSION.  The function checks the version at 
runtime, while the macro checks the version at build time.

The effect of using the macro is that the bug can suddenly show up after 
a gtk update, and a rebuild of emacs with the new gtk is required.  See

   https://cygwin.com/ml/cygwin/2017-03/msg00280.html

Ken

bug#23144: shrinking windows with gtk 3.20

[martin rudalics]

 > Yaakov Selkowitz has pointed out that the fix for this bug on the
 > emacs-25 branch should have used the function gtk_check_version rather
 > than the macro GTK_CHECK_VERSION.  The function checks the version at
 > runtime, while the macro checks the version at build time.

 > The effect of using the macro is that the bug can suddenly show up
 > after a gtk update, and a rebuild of emacs with the new gtk is
 > required.

gtkutil.c has 19 uses of GTK_CHECK_VERSION and none of the function.  So
we probably should replace them all.  Bit of annoying.

martin

bug#23144: shrinking windows with gtk 3.20

[Ken Brown]

[I've removed Yaakov from the Cc.]

On 3/24/2017 9:24 AM, martin rudalics wrote:
>> Yaakov Selkowitz has pointed out that the fix for this bug on the
>> emacs-25 branch should have used the function gtk_check_version rather
>> than the macro GTK_CHECK_VERSION.  The function checks the version at
>> runtime, while the macro checks the version at build time.
>
>> The effect of using the macro is that the bug can suddenly show up
>> after a gtk update, and a rebuild of emacs with the new gtk is
>> required.
>
> gtkutil.c has 19 uses of GTK_CHECK_VERSION and none of the function.  So
> we probably should replace them all.  Bit of annoying.

Not necessarily.  I think the macro is probably TRT in many (most? all?) 
cases.  In the case at hand, the problem occurs only on the emacs-25 
branch, so I don't think we should worry about the other uses.

Ken

bug#23144: shrinking windows with gtk 3.20

[martin rudalics]

 >> gtkutil.c has 19 uses of GTK_CHECK_VERSION and none of the function.  So
 >> we probably should replace them all.  Bit of annoying.

 > Not necessarily.  I think the macro is probably TRT in many (most?
 > all?) cases.  In the case at hand, the problem occurs only on the
 > emacs-25 branch, so I don't think we should worry about the other
 > uses.

In a sense, yes.  A macro is bad when a GTK "feature" is no more
available after upgrading like in the case at hand.  When a feature is
added due to upgrading it will be automatically incorporated in the next
build.  Only when someone detects that upgrading GTK breaks something
else and his Emacs already uses the upgraded version, downgrading may
also break the build.

Still I think that people who upgrade GTK should rebuild Emacs right
away.  Chances are that an upgraded GTK breaks something not covered by
GTK_CHECK_VERSION as well.

martin

bug#23144: shrinking windows with gtk 3.20

[Eli Zaretskii]

> Cc: Yaakov Selkowitz <yselkowi@redhat.com>, Paul Eggert <eggert@cs.ucla.edu>,
>         Eli Zaretskii <eliz@gnu.org>
> From: Ken Brown <kbrown@cornell.edu>
> Date: Fri, 24 Mar 2017 09:01:56 -0400
> 
> Yaakov Selkowitz has pointed out that the fix for this bug on the 
> emacs-25 branch should have used the function gtk_check_version rather 
> than the macro GTK_CHECK_VERSION.  The function checks the version at 
> runtime, while the macro checks the version at build time.
> 
> The effect of using the macro is that the bug can suddenly show up after 
> a gtk update, and a rebuild of emacs with the new gtk is required.  See
> 
>    https://cygwin.com/ml/cygwin/2017-03/msg00280.html

Thanks for letting us know.

The emacs-25 branch cannot accept such changes, and the problem
doesn't exist on master.  So I guess there's nothing we should do
about this.

I wish someone we had some GTK expert on board to catch these issues
in due time...

bug#23144: shrinking windows with gtk 3.20

[Ken Brown]

[Removed Yaakov from the Cc.]

On 3/24/2017 9:35 AM, Eli Zaretskii wrote:
> The emacs-25 branch cannot accept such changes, and the problem
> doesn't exist on master.  So I guess there's nothing we should do
> about this.

Perhaps this should be fixed on the branch after the release of 
emacs-25.2, in case there's ever an emacs-25.3.

Ken

bug#23144: shrinking windows with gtk 3.20

[Eli Zaretskii]

> Cc: 23144@debbugs.gnu.org, eggert@cs.ucla.edu
> From: Ken Brown <kbrown@cornell.edu>
> Date: Fri, 24 Mar 2017 10:08:19 -0400
> 
> On 3/24/2017 9:35 AM, Eli Zaretskii wrote:
> > The emacs-25 branch cannot accept such changes, and the problem
> > doesn't exist on master.  So I guess there's nothing we should do
> > about this.
> 
> Perhaps this should be fixed on the branch after the release of 
> emacs-25.2, in case there's ever an emacs-25.3.

Maybe.  It isn't clear yet that there will be Emacs 25.3.

In any case, it's somewhat disturbing that we allow a GTK version
which behaves differently from the one used to build Emacs to be used
with the same Emacs binary.  Perhaps we should test this at startup
and require recompilation?