public class Gdk extends Object
Gdk...which give you access to lower level drawing constructs; these are mapped in java-gnome as the various classes within package
This particular class, on the other hand, simply contains some of the infrastructure necessary to permit multi-threaded access to GDK, GTK, and other GNOME libraries.
None of the other Java graphical toolkits out there let you make GUI calls from threads other than the "main" one; they're all single threaded. Even if all you want to do is a quick worker thread to carry out some input validation in the background after the user presses "OK", you have to jump through horrific contortions to do so safely, resulting in cumbersome, clunky code. By contrast, the java-gnome 4.0 bindings of GTK are transparently thread safe. We integrate properly with the underlying GDK thread lock and as a result you can safely make calls to various GTK methods from worker threads.
Threading and GNOME is tricky. This class mostly exists for the purpose of holding an object to serve as the global threading monitor and so that when the lock appears in thread dumps it has a useful name.
Every call made to the native libraries is protected by entering "the
master GDK lock"; those familiar with the C side of things would be used to
doing this via
gdk_threads_leave(). When you initialize your java-gnome
GDK is carefully configured so that the lock used is actually a Java side
monitor and therefore reentrant; nested calls all behave properly.
Note that when in a signal handler callback the GDK lock is already held
(you're "in" the main loop when a callback happens), but since it just
works transparently you don't need to worry about it. If you do find a need
to take the lock into account explicitly in your own code, the object is
|Modifier and Type||Class and Description|
An inner class for the purely cosmetic purpose of giving an explicit name to the global GDK lock.
|Modifier and Type||Field and Description|
The global monitor used to regulate access to GTK functions.
public static final Gdk.Lock lock
synchronizedmonitors are reentrant you can proceed with calling other java-gnome methods transparently, but keep in mind that you are blocking the main loop during signal callbacks.
Most of the time you simply don't need to know about this; but should you have some reason to take the global GDK lock yourself, you can access it via this field.