Re: deprecating gdk threads

[Matthias Clasen <matthias clasen gmail com>]

The good thing is that we have enough time to work this out - GTK+ 4
will not appear overnight.

In the meantime, here are some hints for how to deal with fallout from
the deprecation of GDK_THREADS_ENTER/LEAVE in the short term:

1. There's no point anymore in the macro wrappers
GDK_THREADS_ENTER/LEAVE - these used to be defined differently
depending on whether GTK+ was built with thread support. Nowadays it
alway is, so you should just use gdk_threads_enter/leave directly.
Making this change will make most of the build breakage in current
jhbuild go away - unless you build with -Werror
-Wdeprecated-declarations.

2. We have never done a great job of explaining when
gdk_threads_enter/leave are required, it seems - as a consequence, a
good number of the critical sections I've seen marked throughout my
jhbuild checkout are unnecessary. If your application doesn't call
gdk_threads_init or gdk_threads_set_lock_functions, there's no need to
use enter/leave. Libraries are a different story, of course.

3. To get rid of the deprecation warnings you can add
-DGDK_VERSION_MIN_REQUIRED=GDK_VERSION_3_4 to your CFLAGS. By default,
we set this to the next stable version (GDK_VERSION_3_6), which means
that you see deprecation warnings for
api that is being deprecated this cycle. Setting it to GDK_VERSION_3_4
makes it so that you only get warnings for things that were already
deprecated in 3.4

(CCing ddl, since the hints below are interesting to a wider audience)