org.gnome.gdk

## Class Gdk

- Object
- - 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

    Nested Classes
    Modifier and Type | Class and Description
    --- | ---
    `static class` | `Gdk.Lock` An inner class for the purely cosmetic purpose of giving an explicit name to the global GDK lock.

  - ### Field Summary

    Fields
    Modifier and Type | Field and Description
    --- | ---
    `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.