Re: [java-gnome-hackers] a possible merge strategy

[Colin W. <wa...@ve...>]

On Thu, Oct 16, 2008 at 6:13 PM, Stefan Prelle <st...@pr...> wrote:

> I can imagine that since you already adopted the gstreamer-java object
> layer you are not very happy about thinking about a different one.

The gstreamer-java one was/is pretty nice, but I am not wedded to it,
and am taking another look at the java-gnome layer now.  Some of the
underlying JNI code in jni/ would be relatively straightforward to
use, though this gives me a bit of pause:

	g_idle_add(bindings_java_memory_deref, object);

Granted most programs are going to use the mainloop, but it is valid
to not do so.

The dependency on GTK+ in various parts (e.g. call to gtk_main_quit()
in bindings_java_signal) should really be converted to just
GLib/GObject.

The higher level (bindings/), would be better off using a class (JGIR
uses JNA's Pointer class) instead of just 'long' for pointers.  There
are some things not handled at all - like "notify::" for properties
(JGIR generates signals for these).

The handling of boxed types is just wrong.  "The trick is to figure out
 * whether we are owner of the <code>GBoxed</code> or not...</i>".
Boxed types should always be copied when you get them.  See:
http://library.gnome.org/devel/gobject/unstable/gobject-Boxed-Types.html

I'll take a look in more detail later.