GNOME Bugzilla – Bug 337451
Move all org.gnu.glib classes to glib-java
Last modified: 2007-01-05 00:59:25 UTC
We'd like to eventually move all the org.gnu.glib code out of libgtk-java and putting it into our common base library cunningly named glib-java. Moving the code was always the idea; there was no rush however as Java doesn't care which jar a given package.class comes from, and many different jars [and hence java-gnome libraries] can have (say) org.gnu.glib in it. Recently, however, people have been noting that creating java-gnome ish bindings generally introduces a dependency on libgtk-java which is at times silly (ie seanc's evolution-data-server binding which needs glib stuff but isn't a GTK visual thing so ought not to need to link against libgtk-java) This bug is a tracker: when any bugs blocking this one have cleared, then we can do the move; we will also track the work via comments here. AfC
Created attachment 64565 [details] [review] Patch to autogenerate header files. Here's a patch to update the build process of the jg-common cvs module to prepare for the migration of the other glib classes from libgtk-java. What exactly is our game plan of moving the classes anyway? Off-hand, I believe we need to do the following (in no particular order). -update the autotools process of jg-common -remove the gtk+ dependencies of the org.gnu.glib classes (CustomEvents is an exception) -create a superclass to GtkEvent and place it into org.gnu.glib -duplicate gtk_java.[ch] as glib_java.[ch] (or something) and remove its gtk+ dependencies -have all glib classes use glib_java.[ch] instead -rename the "GObject" methods in gtk_java.[ch] to GtkObject, perform renaming on C files where applicable -move glib classes and C files to jg-common -update classes where applicable to correspond with the loss of the Pixbuf convenience methods
I think this is a good summary of what needs to be done.
Created attachment 64640 [details] [review] Patch to have classes interacting with org.gnu.glib classes to not use Pixbuf-specific methods. Essentially, this patch alters DataColumnPixbuf, ListStore, TreeModel, and TreeStore, to store their values as Objects instead of as Pixbufs. A pixbuf still gets rendered properly from what I've tested against the tree example we have included with libgtk-java. Type checking is also still in place since the parameter takes a org.gnu.gdk.Pixbuf, it's just that the underlying method regards it as a simple object instead of specifically specifying that Value is storing a Pixbuf. This doesn't appear to be relevant since, as I mentioned, the Pixbuf still renders properly on the widget. This "theory" can also be tested against something like an AboutDialog, which as a Pixbuf property under the string literal "logo". aboutDialog.setPixbufProperty("logo", pixbuf) aboutDialog.setJavaObjectProperty("logo", pixbuf) Both of the method calls above produces the exact same results, the GtkAboutDialog will be rendered with the pixbuf displayed. I feel that this workaround effectively removes the need for the org.gnu.gtk.(Gtk)Type and org.gnu.gtk.(Gtk)Value classes that were considered to be implemented from previous discussions on IRC. This should be safe to be committed against current CVS head (in the sense that this doesn't depend on having the org.gnu.glib migration in effect). I'm hoping that developers that uses Pixbuf in their ListStores or TreeStores can give this patch a whirl and see if all is still well.
Created attachment 67713 [details] [review] Updates autogen.sh and Makefile.am to configure the newly imported classes and C files. To run autogen.sh, please move all glib C files and Java files to their respective folders (except CustomEvents, that stays in libgtk-java). Along with gtk_java.c attached below and gtk_java.h from the libgtk-java's src/jni folder.
Created attachment 67714 [details] New getGObjectHandle-related C file that doesn't use gtk/gtk.h. Place in glib-java/src/jni.
Created attachment 67716 [details] [review] Patch to remove gtk dependencies on org.gnu.glib's classes. This patch is massive because of the removal of the gdk_threads_enter() (and such) function calls from the C file. This patch will also create a org.gnu.glib.GEvent class, which is essentially synonymous with the GtkEvent class.
To reiterate and to correct what I said incorrectly in comment #4: 1. Apply patch 67713 to jg-common/glib-java (hereinafter referred to as glib-java solely). 2. Apply patch 67716 to libgtk-java. 3. Add attachment 67714 [details] as glib_java.c in glib-java/src/jni. 4. Copy libgtk-java/src/jni/gtk_java.h to glib-java/src/jni/glib_java.h (no internal source code changes are necessary, just copy it). 5. Move all glib C and Java source files (including GEvent.java that should've been created by patch 67716 but maybe I screwed up, and excluding CustomEvents.java and org_gnu_glib_CustomEvents.c) into their respective src/jni src/java folders in glib-java. 6. Remove all previous installations of CVS head for safety's sake. 7. Now configure away with ./autogen.sh and pray that I did it right.
If everything goes well, getGObjectHandle (and others) within gtk_java.[ch] will be renamed to getGtkObjectHandle (and etc...). That will come later. No changes to our other projects are currently necessary since they all reference gtk_java.h, so the fact that both glib_java.h and gtk_java.h currently both has a function named getGObjectHandle does not introduce any conflicts.
Initial inspection looks good. I'm pretty much inclined to tell you to go ahead and apply. The biggest thing to watch out for will be getting the `cvs removes` correct. AfC
The migration has been committed into CVS. Per stated above, all the classes has been moved into jg-common/glib-java except for org.gnu.glib.CustomEvents.