bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#28189: 26.0.50; Emacs uses deprecated function gtk_window_parse_geom


From: Philipp Stephani
Subject: bug#28189: 26.0.50; Emacs uses deprecated function gtk_window_parse_geometry
Date: Sun, 27 Aug 2017 13:34:14 +0000



martin rudalics <rudalics@gmx.at> schrieb am Sa., 26. Aug. 2017 um 11:29 Uhr:
 > I've attached a patch that fixes all deprecation warnings. It's not
 > intended to be installed as-is, more as a baseline for discussion. Some of
 > the functions have straightforward replacements, others are harder to
 > replace, yet others have vanished altogether.

I think you should install most of it right now so we have enough time
to test it before a release.  There are people who build with GTK 3.22
and could tell us whether it breaks anything (substantially, at least).
The sooner we know the better.

OK, I've pushed all the "simple" changes for now.
 

This one

+#if GTK_CHECK_VERSION (3, 16, 0)
+      emacs_abort ();
+#else

looks a bit harsh and the corresponding logic appears quite contrived.
Maybe the entire function should be rewritten.

The underlying issue here is that GTK no longer seems to have a concept of a "background color", but Emacs still assumes that concept exists.
 

Removing the gtk_adjustment_changed calls should be tested ASAP.

How could that be tested?

  
+  /* FIXME: This function assumes that GdkMonitor objects are never
+   * destroyed, even if the monitor is unplugged.  That’s probably the
+   * case, but should be verified.  */

If this is a problem it is a problem already now.  Or am I missing
something?

I think you're right, I've removed the comment. I was concerned about the lifetime of the monitor objects, but I can't imagine this being an issue.
 

+#if GTK_CHECK_VERSION (3, 22, 0)
+  /* FIXME: We should pass the GDK event to this function instead of
+   * synthesizing it.  */

(I think you might want to get this from event_handler_gdk)

I don't think that's possible, because the filter is run before the GTK event is even created, so it has no access to it. In fact, Emacs appears to swallow most X events before they are translated to GTK events.
This should be fixed "for real" by creating a gtk3term, which doesn't use any X functions. It appears to me that the current "X with a bit of GTK sprinkled on top" can't work any more.
 

I have no idea about the cairo related change. 

That's only used for the visible bell, which still works after the change. 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]