Re: Backwards compatibility issues with GDK 2.4

[Mark McLoughlin <mark skynet ie>]

Hi,

On Wed, 2004-04-21 at 23:24, Mike Hearn wrote:
> Hi,
> 
> For GDK 2.4 a patch [1] was integrated which effectively rewrites code to
> give it an implicit dependency on GDK 2.4 only symbols.

	The exact issue being that GDK_THREADS_ENTER() changed in the following
way:

 #  define GDK_THREADS_ENTER()	G_STMT_START {	\
-      if (gdk_threads_mutex)                 	\
-        g_mutex_lock (gdk_threads_mutex);   	\
+      if (gdk_threads_lock)                 	\
+        (*gdk_threads_lock) ();			\

	Meaning that a program which uses GDK_THREADS_ENTER() which is built
against 2.4 will fail to run against 2.2.

> This is problematic, because it means that developers who upgrade to GTK
> 2.4 for themselves, but do not wish to give their software a
> hard dependency on 2.4 just yet can easily do so without even being aware
> of it. In other words users can be forced into upgrading GTK if they wish
> to use binaries compiled by somebody else on a 2.4 system, even if that
> software has explicitly avoided functions marked as "Since 2.4".

	The answer is that anyone distributing binaries that are intended to be
run against 2.2 should not build them against 2.4, IMHO.

	I really think that is the only answer because changes like this are
quite common with any library - e.g. take this one made between gtk+ 2.0
and 2.2:

-#define GDK_ROOT_PARENT()             ((GdkWindow *)gdk_parent_root)
+#ifndef GDK_DISABLE_DEPRECATED
+#define GDK_ROOT_PARENT()             (gdk_get_default_root_window ())

	Basically, if you don't just say "this is expected behaviour, you
should not expect this to work" and try and work around this particular
issue, it doesn't solve the problem in general. We will continue to see
things like this coming up in the future.

Cheers,
Mark.