* bug#23144: shrinking windows with gtk 3.20
@ 2016-03-28 20:52 Matthias Clasen
2016-03-29 15:18 ` martin rudalics
` (3 more replies)
0 siblings, 4 replies; 28+ messages in thread
From: Matthias Clasen @ 2016-03-28 20:52 UTC (permalink / raw
To: 23144
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2016-03-28 20:52 bug#23144: shrinking windows with gtk 3.20 Matthias Clasen
@ 2016-03-29 15:18 ` martin rudalics
2016-03-29 16:02 ` Eli Zaretskii
2016-03-31 16:09 ` John Wiegley
2016-04-02 0:03 ` Paul Eggert
` (2 subsequent siblings)
3 siblings, 2 replies; 28+ messages in thread
From: martin rudalics @ 2016-03-29 15:18 UTC (permalink / raw
To: Matthias Clasen, 23144
> 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2016-03-29 15:18 ` martin rudalics
@ 2016-03-29 16:02 ` Eli Zaretskii
2016-03-29 17:20 ` martin rudalics
2016-03-31 16:09 ` John Wiegley
1 sibling, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2016-03-29 16:02 UTC (permalink / raw
To: martin rudalics; +Cc: 23144, matthias.clasen
> 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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2016-03-29 16:02 ` Eli Zaretskii
@ 2016-03-29 17:20 ` martin rudalics
0 siblings, 0 replies; 28+ messages in thread
From: martin rudalics @ 2016-03-29 17:20 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 23144, matthias.clasen
> 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2016-03-29 15:18 ` martin rudalics
2016-03-29 16:02 ` Eli Zaretskii
@ 2016-03-31 16:09 ` John Wiegley
2016-04-01 7:48 ` martin rudalics
1 sibling, 1 reply; 28+ messages in thread
From: John Wiegley @ 2016-03-31 16:09 UTC (permalink / raw
To: martin rudalics; +Cc: 23144, Matthias Clasen
>>>>> 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2016-03-31 16:09 ` John Wiegley
@ 2016-04-01 7:48 ` martin rudalics
2016-04-01 9:46 ` Eli Zaretskii
0 siblings, 1 reply; 28+ messages in thread
From: martin rudalics @ 2016-04-01 7:48 UTC (permalink / raw
To: John Wiegley; +Cc: 23144, Matthias Clasen
> 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2016-04-01 7:48 ` martin rudalics
@ 2016-04-01 9:46 ` Eli Zaretskii
0 siblings, 0 replies; 28+ messages in thread
From: Eli Zaretskii @ 2016-04-01 9:46 UTC (permalink / raw
To: martin rudalics; +Cc: jwiegley, matthias.clasen, 23144
> 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?
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2016-03-28 20:52 bug#23144: shrinking windows with gtk 3.20 Matthias Clasen
2016-03-29 15:18 ` martin rudalics
@ 2016-04-02 0:03 ` Paul Eggert
2016-04-02 7:01 ` Eli Zaretskii
2016-05-16 6:53 ` Paul Eggert
2017-03-24 13:01 ` Ken Brown
3 siblings, 1 reply; 28+ messages in thread
From: Paul Eggert @ 2016-04-02 0:03 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 23144, Matthias Clasen
> 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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2016-04-02 0:03 ` Paul Eggert
@ 2016-04-02 7:01 ` Eli Zaretskii
2016-04-02 15:19 ` Matthias Clasen
0 siblings, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2016-04-02 7:01 UTC (permalink / raw
To: Paul Eggert; +Cc: 23144, matthias.clasen
> 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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2016-04-02 7:01 ` Eli Zaretskii
@ 2016-04-02 15:19 ` Matthias Clasen
2016-04-02 15:47 ` Eli Zaretskii
0 siblings, 1 reply; 28+ messages in thread
From: Matthias Clasen @ 2016-04-02 15:19 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 23144, Paul Eggert
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2016-04-02 15:19 ` Matthias Clasen
@ 2016-04-02 15:47 ` Eli Zaretskii
2016-04-02 16:06 ` martin rudalics
0 siblings, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2016-04-02 15:47 UTC (permalink / raw
To: Matthias Clasen; +Cc: 23144, eggert
> 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2016-04-02 15:47 ` Eli Zaretskii
@ 2016-04-02 16:06 ` martin rudalics
2016-04-02 16:28 ` Eli Zaretskii
0 siblings, 1 reply; 28+ messages in thread
From: martin rudalics @ 2016-04-02 16:06 UTC (permalink / raw
To: Eli Zaretskii, Matthias Clasen; +Cc: 23144, eggert
> 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2016-04-02 16:06 ` martin rudalics
@ 2016-04-02 16:28 ` Eli Zaretskii
2016-04-02 17:27 ` Matthias Clasen
0 siblings, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2016-04-02 16:28 UTC (permalink / raw
To: martin rudalics; +Cc: 23144, eggert, matthias.clasen
> 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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2016-04-02 16:28 ` Eli Zaretskii
@ 2016-04-02 17:27 ` Matthias Clasen
2016-04-02 17:32 ` Eli Zaretskii
0 siblings, 1 reply; 28+ messages in thread
From: Matthias Clasen @ 2016-04-02 17:27 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Paul Eggert, 23144
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...
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2016-04-02 17:27 ` Matthias Clasen
@ 2016-04-02 17:32 ` Eli Zaretskii
2016-04-02 23:20 ` Matthias Clasen
0 siblings, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2016-04-02 17:32 UTC (permalink / raw
To: Matthias Clasen; +Cc: eggert, 23144
> 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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2016-04-02 17:32 ` Eli Zaretskii
@ 2016-04-02 23:20 ` Matthias Clasen
2016-04-03 2:36 ` Eli Zaretskii
0 siblings, 1 reply; 28+ messages in thread
From: Matthias Clasen @ 2016-04-02 23:20 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Paul Eggert, 23144
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2016-04-02 23:20 ` Matthias Clasen
@ 2016-04-03 2:36 ` Eli Zaretskii
0 siblings, 0 replies; 28+ messages in thread
From: Eli Zaretskii @ 2016-04-03 2:36 UTC (permalink / raw
To: Matthias Clasen; +Cc: eggert, 23144
> 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?
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2016-03-28 20:52 bug#23144: shrinking windows with gtk 3.20 Matthias Clasen
2016-03-29 15:18 ` martin rudalics
2016-04-02 0:03 ` Paul Eggert
@ 2016-05-16 6:53 ` Paul Eggert
2016-05-16 8:21 ` martin rudalics
2016-05-16 15:53 ` Eli Zaretskii
2017-03-24 13:01 ` Ken Brown
3 siblings, 2 replies; 28+ messages in thread
From: Paul Eggert @ 2016-05-16 6:53 UTC (permalink / raw
To: 23144; +Cc: Matthias Clasen
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2016-05-16 6:53 ` Paul Eggert
@ 2016-05-16 8:21 ` martin rudalics
2016-05-16 15:53 ` Eli Zaretskii
1 sibling, 0 replies; 28+ messages in thread
From: martin rudalics @ 2016-05-16 8:21 UTC (permalink / raw
To: Paul Eggert, 23144; +Cc: Matthias Clasen
> 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2016-05-16 6:53 ` Paul Eggert
2016-05-16 8:21 ` martin rudalics
@ 2016-05-16 15:53 ` Eli Zaretskii
2016-05-16 17:11 ` Paul Eggert
1 sibling, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2016-05-16 15:53 UTC (permalink / raw
To: Paul Eggert; +Cc: 23144, matthias.clasen
> 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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2016-03-28 20:52 bug#23144: shrinking windows with gtk 3.20 Matthias Clasen
` (2 preceding siblings ...)
2016-05-16 6:53 ` Paul Eggert
@ 2017-03-24 13:01 ` Ken Brown
2017-03-24 13:24 ` martin rudalics
2017-03-24 13:35 ` Eli Zaretskii
3 siblings, 2 replies; 28+ messages in thread
From: Ken Brown @ 2017-03-24 13:01 UTC (permalink / raw
To: 23144; +Cc: Yaakov Selkowitz, Paul Eggert
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2017-03-24 13:01 ` Ken Brown
@ 2017-03-24 13:24 ` martin rudalics
2017-03-24 13:38 ` Ken Brown
2017-03-24 13:35 ` Eli Zaretskii
1 sibling, 1 reply; 28+ messages in thread
From: martin rudalics @ 2017-03-24 13:24 UTC (permalink / raw
To: Ken Brown, 23144; +Cc: Yaakov Selkowitz, Paul Eggert
> 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2017-03-24 13:24 ` martin rudalics
@ 2017-03-24 13:38 ` Ken Brown
2017-03-24 18:52 ` martin rudalics
0 siblings, 1 reply; 28+ messages in thread
From: Ken Brown @ 2017-03-24 13:38 UTC (permalink / raw
To: martin rudalics, 23144; +Cc: Paul Eggert
[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
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2017-03-24 13:38 ` Ken Brown
@ 2017-03-24 18:52 ` martin rudalics
0 siblings, 0 replies; 28+ messages in thread
From: martin rudalics @ 2017-03-24 18:52 UTC (permalink / raw
To: Ken Brown, 23144; +Cc: Paul Eggert
>> 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2017-03-24 13:01 ` Ken Brown
2017-03-24 13:24 ` martin rudalics
@ 2017-03-24 13:35 ` Eli Zaretskii
2017-03-24 14:08 ` Ken Brown
1 sibling, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2017-03-24 13:35 UTC (permalink / raw
To: Ken Brown; +Cc: 23144, eggert, yselkowi
> 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...
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2017-03-24 13:35 ` Eli Zaretskii
@ 2017-03-24 14:08 ` Ken Brown
2017-03-24 14:27 ` Eli Zaretskii
0 siblings, 1 reply; 28+ messages in thread
From: Ken Brown @ 2017-03-24 14:08 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 23144, eggert
[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
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#23144: shrinking windows with gtk 3.20
2017-03-24 14:08 ` Ken Brown
@ 2017-03-24 14:27 ` Eli Zaretskii
0 siblings, 0 replies; 28+ messages in thread
From: Eli Zaretskii @ 2017-03-24 14:27 UTC (permalink / raw
To: Ken Brown; +Cc: 23144, eggert
> 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?
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2017-03-24 18:52 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-28 20:52 bug#23144: shrinking windows with gtk 3.20 Matthias Clasen
2016-03-29 15:18 ` martin rudalics
2016-03-29 16:02 ` Eli Zaretskii
2016-03-29 17:20 ` martin rudalics
2016-03-31 16:09 ` John Wiegley
2016-04-01 7:48 ` martin rudalics
2016-04-01 9:46 ` Eli Zaretskii
2016-04-02 0:03 ` Paul Eggert
2016-04-02 7:01 ` Eli Zaretskii
2016-04-02 15:19 ` Matthias Clasen
2016-04-02 15:47 ` Eli Zaretskii
2016-04-02 16:06 ` martin rudalics
2016-04-02 16:28 ` Eli Zaretskii
2016-04-02 17:27 ` Matthias Clasen
2016-04-02 17:32 ` Eli Zaretskii
2016-04-02 23:20 ` Matthias Clasen
2016-04-03 2:36 ` Eli Zaretskii
2016-05-16 6:53 ` Paul Eggert
2016-05-16 8:21 ` martin rudalics
2016-05-16 15:53 ` Eli Zaretskii
2016-05-16 17:11 ` Paul Eggert
2017-03-24 13:01 ` Ken Brown
2017-03-24 13:24 ` martin rudalics
2017-03-24 13:38 ` Ken Brown
2017-03-24 18:52 ` martin rudalics
2017-03-24 13:35 ` Eli Zaretskii
2017-03-24 14:08 ` Ken Brown
2017-03-24 14:27 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.