[java-gnome-hackers] Idle coverage

[Andrew C. <an...@op...>]

Guillaume uncovered a bug; basically the new Application coverage we
introduced doesn't work with java-gnome's multi-thread safety because
GTK itself is no longer thread safe. While they haven't yet removed what
they've deprecated, the new GtkApplication code doesn't release the GDK
lock in g_application_run() like gtk_main() does. So, bam, race. Boo.

This has been coming for a while, and despite my intense disappointment
about it all, will now be like every other GUI toolkit out there: not
thread safe. Double Boo.

Anyway, if you're working from another thread and need to update your
GTK widgets, you must do so from within the main loop. To get there, you
add an idle handler which will get a callback at some future point. See
http://java-gnome.sourceforge.net/doc/api/4.1/org/gnome/glib/Glib.html#idleAdd(org.gnome.glib.Handler)

It'd really be rather nice if the people with experience with the
toolkit could have a look at this implementation and tell me if it's
done right. In particular, have a look at:
http://research.operationaldynamics.com/bzr/java-gnome/mainline/src/bindings/org/gnome/glib/GMain.c

++

It's an open question whether we still need our implementation of the
GDK lock. The code is all there, and if nothing else it'll show you a
deadlock when you've done something you shouldn't have, ie call GTK from
another thread.

Given the massive capability loss this represents, I rather think we
should remove this as 4.2.0; should I mark it deprecated in 4.1.2?

++

I've also dramatically updated the documentation around the Application
coverage. I _think_ I've got it all squared away now, but perhaps you'll
comment.
http://java-gnome.sourceforge.net/doc/api/4.1/org/gnome/gtk/Application.html

AfC
Sydney