java gnome problems

callback lists for signal handlers

The java/gnome gui system does somewhat suffer from the language problems themselves - as well as frome the signal/slot mechanism that is generally implemented as callbacks over lists with anonymous class objects - and that is just the way it is done in java/swing and friends.

The problem with that is they are never stored or queued! Actually, such signal indicator are really callbacks that will nest deeply and whenever there is a complex functionality bound to the end of a callback then you might see the GUI widgets hang for a while. That's because the GUI widgets can not run themselves and especially not react to user events such as mouse clicks or keypress events.

However, beyond java/gnome there is yet another option that has some stronger relation to outside code than the stuff shown up to here. Well, of course it is somehow related to a background worker thread but this time it is a little different - we do not synchronize the widget methods but instead we register methods near the gtk mainloop.

For that it is best to create your own local class being the "signal" type and "marshaller" of your notification message to be stored asynchronously.

  class SetEvent implements Runnable {
     TargetWidget widget;
     int param;
     public SetEvent(TargetWidget _widget, int _param) {
       widget = _widget; param = _param;
     }
     public void run() {
       widget.realSet(param); 
     }
  }
  public void someCallback(int param) {
     org.gnu.gtk.glib.CustomEvents.addEvent(new SetEvent(this, param);
  }

That mode allows to build an asynchronous worker thread for gtk. The worker thread may do a lot of time-consuming stuff without a need to spin on gtk_main_iteration. Whenever the worker thread yields a value that should be represented in the gui then it marshals a signal event and registers it in the gtk_main event-list as shown above. Since the gtk_main is only run on the main thread we can assert that no errornous multi-thread behavior creeps in - the marshalled signal will be executed in the gui-thread context. (Remember that the java-gtk is much more unforgiving about thread-problems than java/swing).

Build the package

The java-gnome bindings are not complete and the project makers have actually stopped at extending it more and more - instead they did jump on the gtk-2.5 bandwagon where there is a set of spec files under creation that can guide the compilation process of native interface modules for (real) object-oriented languages. But that is not usable yet for the average packager, so I used the 0.8.2 release of java-gnome.

Compiling it had been somewhat a pain - to do it right it requires a lot of native devel packages (including gtkhtml and vte) plus a number of build tools that people have usually not around - like gcj / gcc-java. I do not quite know why the "configure" script looks for that one specifically. That gcj package happened to put some files in the very same location as the "java/sdk" package does, e.g. the "javac" compiler.

Furthermore java-gnome had some "PasswordEntry" widget wrapper around that does not exist in gtk-2.0 installation headers. Similar to that, the requirement of vte > 0.11 looks useless as is compiles fine with just vte = 0.10. Plus the "make install" target is so weird it makes some local directories not searchable. After all, I do now use four patches with compiling the java-gnome package in my rpm spec - desperately needed to get it done.

No Derived Widgets

The gtk widgets actually allow to do compositions of gtk and other gtk objects. Similar to SWT, one needs a createWidgets function that builds the widget parts instead of the constructor. But in actual real life I did not care much, and most classes were derived from org.gnu.gtk.Frame. That is originally incorrect since a "Frame" builds an extra thin line on the screen. (it turned out that a "Bin" does not work correct as widget container).

Similar, it is not possible to define your own signal types on the uppermost level (internally, event tables are created). One needs to help out here with going to the conanic form. After all, doing inits in the class implementations looks better. ...