Since GLib ≥ 2.41, attempting to release an unlocked mutex will abort(),
as it happens on most systems already.
Given the lack of proper documentation on how to use GDK with threads,
there is code in the wild that does:
gdk_threads_init ();
gdk_init ();
...
gtk_main ();
instead of the idiomatically correct:
gdk_threads_init ();
gdk_threads_enter ();
gtk_init ();
...
gtk_main ();
...
gdk_threads_leave ();
Which means that gtk_main() will try to release the GDK lock, and thus
trigger an error from GLib.
we cannot really fix all the wrong code everywhere, and since it does
not cost us anything, we can work around the issue inside GDK itself, by
trying to acquire the GDK lock inside gdk_threads_leave() with
trylock().
https://bugzilla.gnome.org/show_bug.cgi?id=735428
It's not necessary anymore because gdk_display_manager_get() always
succeeds and the value is independant of when it was called as it's no
longer backend specific.
Add GInitable interface with a default implementation that always
succeeds. This allows backends to override the GInitable implementation
and add their own checks to determine if the backend can be loaded. If
a backend cannot be loaded, GDK can attempt to load the next available
backend.
Since backends may need to read any relevant options (such as the
display flag) to determine if they can be created successfully, this
patch also removes calls that attempt to create the display manager
before the options have been parsed.
https://bugzilla.gnome.org/show_bug.cgi?id=694465
The story is slightly different for applications vs libraries;
make it clear that libraries should continue using the lock so
we don't break applications that haven't been ported to the
'single thread' model yet.
This commit deprecates gdk_threads_init, gdk_threads_enter,
gdk_threads_leave and gdk_threads_set_lock_functions. Using GTK+
from multiple threads does not work at all on Windows, and is
problematic on other platforms as well. We want to move to a world
where all GTK+ calls are made from the main thread.
Use g_main_context_invoke, g_idle_add and related functions if you
need to schedule GTK+ calls from other threads.
http://bugzilla.gnome.org/show_bug.cgi?id=680754
GDK_NATIVE_WINDOWS was a way to keep some old apps running that did weird
things in gtk2. We should not have to carry this forwards in gtk 3.x.
We do however keep a g_warning() call reminding people of this fact to
ease debugging when they try to port their applications.
https://bugzilla.gnome.org/show_bug.cgi?id=644119
This change does not introduce any functionality change, mostly
cosmtic cleanups, like re-linebreak when introduced annotations messed
up indentation or whitespace errors fixes.
Remove the --sync option and remove the possibility of backend-specific
commandline options altogether. --sync is being replaced by
a GDK_SYNCHRONIZE environment variable.
