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) _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
