Overview  Package   Class 
java-gnome version 4.0.19
 PREV CLASS   NEXT CLASS FRAMES    NO FRAMES    All Classes
SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD

org.gnome.gdk
Class Gdk

Object
  extended by org.gnome.gdk.Gdk

public class Gdk
extends Object

The backend to GTK which talks to the actual screen is GDK. There are various classes with the prefix Gdk... which give you access to lower level drawing constructs; these are mapped in java-gnome as the various classes within package org.gnome.gdk.

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.

Thread safety in java-gnome

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_enter() and gdk_threads_leave(). When you initialize your java-gnome program with Gtk.init(), 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 available here, Gdk.lock.

Since:
4.0.3
Author:
Andrew Cowie

Nested Class Summary
static class Gdk.Lock
          An inner class for the purely cosmetic purpose of giving an explicit name to the global GDK lock.
 
Field Summary
static Gdk.Lock lock
          The global monitor used to regulate access to GTK functions.
 
Method Summary
 
Methods inherited from class Object
equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
 

Field Detail

lock

public static final Gdk.Lock lock
The global monitor used to regulate access to GTK functions. Any time you call a java-gnome function you will enter the lock on this object. As it happens, when you receive a callback you are "in" the main loop, and thus within the lock held on this object. Because Java synchronized monitors 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.

Overview  Package   Class 

java-gnome
 PREV CLASS   NEXT CLASS FRAMES    NO FRAMES    All Classes
SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD