java-gnome-developer — For people using the bindings to write their own applications

RE: [Java-gnome-developer] Final patch and a question

[Jeff M. <ku...@ne...>]

> What I don't understand is why you would ever want to use 
> makeBaseObjectSubclass().  There still dozens of methods using it 
> in the code and I just can't think of any reason why you would 
> not want to user to be able to typecast the object back to its 
> proper type.
> 

You are correct.  I just haven't had the time to make all of
the changes and test them.  I will probably change all of this
over the weekend.

[Java-gnome-developer] Final patch and a question

[Julian F. <jul...@be...>]

Ok, I grabbed the newest version out of CVS this afternoon and it now works=
 with only my patches to the LibGlade stuff which I will include at the=
 bottom of this email. Hopefully I will now be able to use a version=
 straight out of the repository.  Changes are as follows:

- The biggest change in there is changing all the longs to ints.  This was=
 necessary to make it work on Solaris.  I would appreciate if someone could=
 test this on linux or whatever else to see if it breaks it there or if it=
 still works.
- I added a parameter to the LibGlade constructor which takes a widget name=
 and beings loading the file from that point in the tree.  This is a=
 parameter that the C libglade library already takes, but Avi added it in a=
 version of the code after you grabbed it from him.
- I added some exception handling and error checking code.  I suspect this=
 suffers from the same problem of rethrowing the exception before the=
 exceptions are cleared or something?  In trying to come up with a way to=
 allow the Java user to decide whether the inability to bind a signal=
 should kill the file loading (I definitely do not want it to do this) I=
 came up with the idea of having a  method in the Java side of LibGlade=
 that was called.  The user can subclass LibGlade to make the method=
 display an error message however the user likes.  The return value=
 determines whether the C code throws an exception or not.  You can nix=
 this if you like, it was just the best I could come up with.
- And finally, I reenabled some code you had commented out regarding the=
 target parameter of the signal connection.  This functionality is needed=
 to allow the Gtk objects to send messages to each other (this is allowed=
 for in Glade).

Let me know if anything is unclear or if you'd like me to change something.

And finally, you wrote:

>4) Subject:  parent missing from GtkWidget - 
>> But what I can't quite figure out is why the java objects are
>> created as GtkWidgets instead of being just returned as GtkWidgets.
>This is a very good point.  I have been meaning to make this change
>but it hasn't been my highest priority.  I have just added a method
>to BaseObject called makeBaseObjectClass.  This method detects the
>correct Gtk type and builds a peer for it much the same way as
>the makeBaseObjectSubclass.  I will be updating the code generator
>to use this method where appropriate over the next few days.

What I don't understand is why you would ever want to use=
 makeBaseObjectSubclass().  There still dozens of methods using it in the=
 code and I just can't think of any reason why you would not want to user=
 to be able to typecast the object back to its proper type.

The patch follows immediately below.

Thanks,

Julian



Index: LibGlade.java
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/java-gnome/java-gnome/src/other/LibGlade.java,v
retrieving revision 1.2
diff -u -r1.2 LibGlade.java
--- LibGlade.java       2001/02/15 09:02:54     1.2
+++ LibGlade.java       2001/03/31 04:56:04
@@ -16,6 +16,7 @@
  *
  * @author Avi Bryant
  * @author Jean van Wyk
+ * @author Julian Fitzell
  *
  */
 
@@ -31,11 +32,16 @@
 
     protected Map widgets =3D new Hashtable();
     protected Object owner;
-       
-    public LibGlade(String file, Object owner)
+
+    public LibGlade(Object owner, String file, String root)
     {
        this.owner =3D owner;
-       glade =3D construct(file);
+       try {
+           glade =3D construct(file, root);
+       }
+       catch(Exception e) {
+           System.err.println("LibGlade error: " + e);
+       }
     }
 
     public GtkWidget getWidget(String name)
@@ -44,7 +50,7 @@
 
        if(widget =3D=3D null)
        {
-           long nativepeer =3D getNativeWidget(name);
+           int nativepeer =3D getNativeWidget(name);
            if(nativepeer !=3D 0)
                widget =3D getWidget(nativepeer);
        }
@@ -58,20 +64,20 @@
 
        if(widget =3D=3D null)
        {
-           long nativepeer =3D getNativeWidgetByLongName(name);
+           int nativepeer =3D getNativeWidgetByLongName(name);
            if(nativepeer !=3D 0)
                widget =3D getWidget(nativepeer);
        }
                
        return widget;
     }
-                       
-    protected native long construct(String file);
+
+    protected native long construct(String file, String root);
 
-    protected native long getNativeWidget(String name);
-    protected native long getNativeWidgetByLongName(String longName);
-    protected native String getWidgetName(long nativepeer);
-    protected native String getWidgetLongName(long nativepeer);
+    protected native int getNativeWidget(String name);
+    protected native int getNativeWidgetByLongName(String longName);
+    protected native String getWidgetName(int nativepeer);
+    protected native String getWidgetLongName(int nativepeer);
        
     protected void connect(String handler, String signal, String data,
        GtkWidget source, Object target)
@@ -85,10 +91,21 @@
            source.signalConnect(signal, handler, target);
     }
 
-    protected GtkWidget getWidget(long nativepeer)
+    protected boolean connectError(Throwable exc)
     {
+       System.err.println("Error connecting Glade signal: " +=
 exc.getMessage());
+
+       //by default we don't want to abort the LibGlade construction
+       return false;
+    }
+
+    protected GtkWidget getWidget(int nativepeer)
+    {
        String widgetLongName =3D getWidgetLongName(nativepeer);
 
+       if (widgetLongName =3D=3D null)
+           return null;
+
        GtkWidget widget =3D (GtkWidget) widgets.get(widgetLongName);
        if(widget =3D=3D null)
        {
@@ -103,5 +120,5 @@
        return widget;
     }
 
-    protected native GtkWidget makeWidget(long nativepeer);
+    protected native GtkWidget makeWidget(int nativepeer);
 } 
Index: gnu_glade_LibGlade.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/java-gnome/java-gnome/src/other/gnu_glade_LibGlade.c,v
retrieving revision 1.2
diff -u -r1.2 gnu_glade_LibGlade.c
--- gnu_glade_LibGlade.c        2001/02/15 09:02:54     1.2
+++ gnu_glade_LibGlade.c        2001/03/31 04:56:04
@@ -33,6 +33,9 @@
     jclass cls;
     jmethodID getWidgetMID;
     jmethodID connectMID;
+    jthrowable exc;  //exception
+    jmethodID errorMID;
+    jboolean errorRet;
 
     jstring handler, signal, data;
     jobject source, target;
@@ -51,68 +54,120 @@
        data =3D 0L;
 
     cls =3D (*env)->GetObjectClass(env, obj);
+    if (cls =3D=3D 0)
+      return;
+
     getWidgetMID =3D (*env)->GetMethodID(env, cls, "getWidget",
-       "(J)Lgnu/gtk/GtkWidget;");
+       "(I)Lgnu/gtk/GtkWidget;");
     connectMID =3D (*env)->GetMethodID(env, cls, "connect",
        "(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Lgnu/gtk/Gtk=
Widget;Ljava/lang/Object;)V");
+    if (getWidgetMID =3D=3D 0 || connectMID =3D=3D 0)
+      return;
+
+    errorMID =3D (*env)->GetMethodID(env, cls, "connectError",=
 "(Ljava/lang/Throwable;)Z");
+    //no need to return if 0... we just don't use it later
 
     source =3D (*env)->CallObjectMethod(env, obj, getWidgetMID, _source);
-//  We want the class that called the XML file to handle it therefore it
-//  should be 0L regardless.
-//  if(_target)
-//     target =3D (*env)->CallObjectMethod(env, obj, getWidgetMID,=
 _target);
-//  else
-    target =3D NULL;
+    exc =3D (*env)->ExceptionOccurred(env);
+    if (exc)
+      {
+       if (errorMID)
+         {
+           errorRet =3D (*env)->CallBooleanMethod(env, obj, errorMID,=
 exc);
+           if (errorRet =3D=3D JNI_TRUE)
+             (*env)->Throw(env, exc);
+         }
+       (*env)->ExceptionClear(env);
+       }
+
+    if(_target)
+      {
+       target =3D (*env)->CallObjectMethod(env, obj, getWidgetMID,=
 _target);
+       exc =3D (*env)->ExceptionOccurred(env);
+       if (exc)
+         {
+           if (errorMID)
+             {
+               errorRet =3D (*env)->CallBooleanMethod(env, obj, errorMID,=
 exc);
+               if (errorRet =3D=3D JNI_TRUE)
+                 (*env)->Throw(env, exc);
+             }
+           (*env)->ExceptionClear(env);
+           }
+      }
+      else
+      target =3D 0L;
        
     (*env)->CallVoidMethod(env, obj, connectMID, handler, signal, data,=
 source, target);
+
+    exc =3D (*env)->ExceptionOccurred(env);
+    if (exc)
+      {
+        if (errorMID)
+          {
+            errorRet =3D (*env)->CallBooleanMethod(env, obj, errorMID,=
 exc);
+            if (errorRet =3D=3D JNI_TRUE)
+              (*env)->Throw(env, exc);
+          }
+       (*env)->ExceptionClear(env);
+       }
 }
 
 JNIEXPORT jlong JNICALL
 Java_gnu_glade_LibGlade_construct
-    (JNIEnv *env, jobject o, jstring file)
+    (JNIEnv *env, jobject o, jstring file, jstring root)
 {
     GladeXML *xml;
     struct jglade_info i;
     char *filename;
+    char *rootname;
 
     i.env =3D env;
     i.o =3D o;
     filename =3D (*env)->GetStringUTFChars(env, file, 0);
 
+    if(root)
+      rootname =3D (*env)->GetStringUTFChars(env, root, 0);
+    else
+      rootname =3D 0L;
+
     glade_init();
 
-    xml =3D glade_xml_new(filename, 0L);
+    xml =3D glade_xml_new(filename, rootname);
     if(xml)
     {
        glade_xml_signal_autoconnect_full(xml, xml_connect, &i);
     }
 
     (*env)->ReleaseStringUTFChars(env, file, filename);
+    if(rootname)
+      (*env)->ReleaseStringUTFChars(env, root, rootname);
 
     return (jlong) xml;
 }      
 
+
 JNIEXPORT jstring JNICALL Java_gnu_glade_LibGlade_getWidgetName
-    (JNIEnv *env, jobject o, jlong nativepeer)
+    (JNIEnv *env, jobject o, jint nativepeer)
 {
-    GtkObject *gtk =3D (GtkObject *)nativepeer;
+    GtkObject *gtk =3D (GtkObject *)(nativepeer);
 
     return (*env)->NewStringUTF(env, glade_get_widget_name(gtk));
 }
 
 JNIEXPORT jstring JNICALL Java_gnu_glade_LibGlade_getWidgetLongName
-    (JNIEnv *env, jobject o, jlong nativepeer)
+    (JNIEnv *env, jobject o, jint nativepeer)
 {
-    GtkObject *gtk =3D (GtkObject *)nativepeer;
+    GtkObject *gtk =3D (GtkObject *)(nativepeer);
 
     return (*env)->NewStringUTF(env, glade_get_widget_long_name(gtk));
 }
 
-JNIEXPORT jlong JNICALL Java_gnu_glade_LibGlade_getNativeWidget
+JNIEXPORT jint JNICALL Java_gnu_glade_LibGlade_getNativeWidget
     (JNIEnv *env, jobject o, jstring namestr)
 {
     char *name =3D (*env)->GetStringUTFChars(env, namestr, 0);
-    jlong result;
+    jint result;
     jclass cls;
     jfieldID fid;
     GladeXML* xml;
@@ -121,18 +176,18 @@
     fid =3D (*env)->GetFieldID(env, cls, "glade", "J");
     xml =3D (*env)->GetLongField(env, o, fid);
 
-    result =3D (jlong) glade_xml_get_widget(xml, name);
+    result =3D (jint) glade_xml_get_widget(xml, name);
     
     (*env)->ReleaseStringUTFChars(env, namestr, name);
 
     return result;
 }
 
-JNIEXPORT jlong JNICALL Java_gnu_glade_LibGlade_getNativeWidgetByLongName
+JNIEXPORT jint JNICALL Java_gnu_glade_LibGlade_getNativeWidgetByLongName
   (JNIEnv *env, jobject o, jstring longnamestr)
 {
     char *longname =3D (*env)->GetStringUTFChars(env, longnamestr, 0);
-    jlong result;
+    jint result;
     jclass cls;
     jfieldID fid;
     GladeXML* xml;
@@ -141,7 +196,7 @@
     fid =3D (*env)->GetFieldID(env, cls, "glade", "J");
     xml =3D (*env)->GetLongField(env, o, fid);
 
-    result =3D (jlong) glade_xml_get_widget_by_long_name(xml, longname);
+    result =3D (jint) glade_xml_get_widget_by_long_name(xml, longname);
     
     (*env)->ReleaseStringUTFChars(env, longnamestr, longname);
 
@@ -149,9 +204,9 @@
 }
 
 JNIEXPORT jobject JNICALL Java_gnu_glade_LibGlade_makeWidget
-    (JNIEnv *env, jobject o, jlong nativepeer)
+    (JNIEnv *env, jobject o, jint nativepeer)
 {
-    GtkObject *gtk =3D (GtkObject *)nativepeer;
+    GtkObject *gtk =3D (GtkObject *)(nativepeer);
     char classname[100];
     jclass cls;

Re: [Java-gnome-developer] Julian's contributions

[Julian F. <jul...@be...>]

Thanks a lot, this seems great.  I've read it once over but I'll have a=
 closer look tomorrow and check out the changes in CVS and go back and see=
 if this addresses all the issues I had.  The project I'm using this on is=
 for a software development course and we're supposed to be packaging it up=
 over the weekend.  If I'm lucky, I may be able to give them an unmodified=
 version of the java-gtk code.

I'll let you know if it's all working or if I had any other changes.  I=
 think I still have an addition to the glade stuff that traverses all the=
 widgets and loads them into the cache and another that lets you get at the=
 array of widgets in the glade object.  This workaround was at Avi's=
 suggestion because libglade doesn't seem to provide any way to get the=
 top-level widget unless you know it's name (I hope I'm remembering the=
 problem correctly) and I needed to browse the widget tree.  Of course,=
 children() also didn't work at the time so I might be able to just add a=
 method to get the top-level widget somehow now.  This code is currently=
 too much of a hack to be worth committing I think.

Julian


On 29/03/01 at 9:30 PM Jeffrey Morgan wrote:

>First of all let me say thank you Julian for all of the patches.  
>I appreciate all of the help I can get.  All of those who are 
>listening I am looking for volunteers.  If you have the time and
>interest I need you!
>
>Sorry it has taken me so long to respond to all of your emails.
>I will address all of them here.
>
>
>1) Subject: Freezing on runtime exception within signal handler
>Great addition.  This code has been added and is now in cvs.
>
>
>2) Subject: GtkContainer::Children()
>In this email you stated that you don't know where to update the
>generator to fix this problem.  This has been fixed and is now
>in cvs.  Let me explain how I fixed this problem and at the same 
>time explain a nice feature of the code generator.
>
>In the src/tools directory you will find a file named JNIProps.txt.
>This file allows you to define how code is generated for specific
>scheme types that are used in the defs file.  The file is very well
>commented and is easy to follow.  The entry for "GList" was as follows:
>
>GList.javaType:     gnu.gdk.GListString
>GList.nativeType:   jobject
>GList.nativeUnwrap: GList *$TO =3D peerOfGListString (env, $FROM);
>GList.nativeWrap:   \
>    $CLEANUP        \
>    return makeGListString (env, ($CALL));
>GList.rawType:      GList *
>
>As you can see it assumed that GLists only contained strings.  I changed
>this scheme type to GListString and made the cooresponding changes
>in the defs file.  I then added a new set of entries for GList.  The
>new entries for GList are as follows:
>
>GList.javaType:     gnu.gtk.GtkWidget[]
>GList.nativeType:   jobjectArray
>GList.nativeUnwrap:                                                     \
>    GList *$TO =3D NULL;=
                                                  \
>    jsize len =3D (*env)->GetArrayLength(env, $FROM);=
                     \
>    int i;                                                              \
>    \n-\n                                                               \
>    for (i =3D 0; i < len; i++) {=
                                         \
>        GtkWidget *widget =3D (*env)->GetObjectArrayElement(env, $FROM,=
 i);\
>        $TO =3D g_list_append($TO, widget);=
                               \
>    }
>GList.nativeWrap:                                                       \
>    GList *list =3D $CALL;=
                                                \
>    int childrenLength =3D g_list_length(list);=
                           \
>    jclass widgetCls =3D (*env)->FindClass(env, "gnu/gtk/GtkWidget");=
     \
>    jobjectArray array =3D NULL;=
                                          \
>    jobject widget;                                                     \
>    GtkWidget *nativeWidget;                                            \
>    if (childrenLength > 0) {                                           \
>        int i;                                                          \
>        for (i =3D 0; i < childrenLength; i++) {=
                          \
>            nativeWidget =3D (GtkWidget*)g_list_nth_data(list, i);=
        \
>            widget =3D makeBaseObjectClass(env, nativeWidget);=
            \
>            if (array =3D=3D NULL)=
                                          \
>                array =3D (*env)->NewObjectArray(env, childrenLength,=
     \
>                                               widgetCls, widget);      \
>            else                                                        \
>                (*env)->SetObjectArrayElement(env, array, i, widget);   \
>        }                                                               \
>    }                                                                   \
>    $CLEANUP        \
>    return array;
>GList.rawType:      GList *
>
>This mechanism makes it very simple to extend the capabilities 
>of the generator by defining new scheme types and adding the 
>appropriate code in this text file.
>
>
>3) Subject:  parent missing from GtkWidget
>This has been fixed and is also in cvs.  I will explain how I
>fixed this problem and also introduce you to another feature of
>the generator.  The generator is far from perfect at this time.
>There are many instances when the generator is unable to generate
>the appropriate code.  To get around this I added the ability to
>insert manual code into the generated code.  In the src/code 
>directory you will find two additional directories; java and glue.  T
>These directories are where you should place manual code.  The
>code found in these files will be inserted into the end for the
>code generated by the code generator.  I added the file GtkWidget.java
>to the java directory and GtkWidget.h and GtkWidget.c to the glue
>directory.  These files contain the fix to you reported problem.
>
>
>4) Subject:  parent missing from GtkWidget - 
>> But what I can't quite figure out is why the java objects are
>> created as GtkWidgets instead of being just returned as GtkWidgets.
>This is a very good point.  I have been meaning to make this change
>but it hasn't been my highest priority.  I have just added a method
>to BaseObject called makeBaseObjectClass.  This method detects the
>correct Gtk type and builds a peer for it much the same way as
>the makeBaseObjectSubclass.  I will be updating the code generator
>to use this method where appropriate over the next few days.
>
>I hope I have answered you questions and addressed all of you
>issues.  If not please let me know.
>
>-Jeff
>
>
>_______________________________________________
>java-gnome-developer mailing list
>jav...@li...
>http://lists.sourceforge.net/lists/listinfo/java-gnome-developer

[Java-gnome-developer] Julian's contributions

[Jeffrey M. <ku...@ne...>]

First of all let me say thank you Julian for all of the patches.  
I appreciate all of the help I can get.  All of those who are 
listening I am looking for volunteers.  If you have the time and
interest I need you!

Sorry it has taken me so long to respond to all of your emails.
I will address all of them here.


1) Subject: Freezing on runtime exception within signal handler
Great addition.  This code has been added and is now in cvs.


2) Subject: GtkContainer::Children()
In this email you stated that you don't know where to update the
generator to fix this problem.  This has been fixed and is now
in cvs.  Let me explain how I fixed this problem and at the same 
time explain a nice feature of the code generator.

In the src/tools directory you will find a file named JNIProps.txt.
This file allows you to define how code is generated for specific
scheme types that are used in the defs file.  The file is very well
commented and is easy to follow.  The entry for "GList" was as follows:

GList.javaType:     gnu.gdk.GListString
GList.nativeType:   jobject
GList.nativeUnwrap: GList *$TO = peerOfGListString (env, $FROM);
GList.nativeWrap:   \
    $CLEANUP        \
    return makeGListString (env, ($CALL));
GList.rawType:      GList *

As you can see it assumed that GLists only contained strings.  I changed
this scheme type to GListString and made the cooresponding changes
in the defs file.  I then added a new set of entries for GList.  The
new entries for GList are as follows:

GList.javaType:     gnu.gtk.GtkWidget[]
GList.nativeType:   jobjectArray
GList.nativeUnwrap:                                                     \
    GList *$TO = NULL;                                                  \
    jsize len = (*env)->GetArrayLength(env, $FROM);                     \
    int i;                                                              \
    \n-\n                                                               \
    for (i = 0; i < len; i++) {                                         \
        GtkWidget *widget = (*env)->GetObjectArrayElement(env, $FROM, i);\
        $TO = g_list_append($TO, widget);                               \
    }
GList.nativeWrap:                                                       \
    GList *list = $CALL;                                                \
    int childrenLength = g_list_length(list);                           \
    jclass widgetCls = (*env)->FindClass(env, "gnu/gtk/GtkWidget");     \
    jobjectArray array = NULL;                                          \
    jobject widget;                                                     \
    GtkWidget *nativeWidget;                                            \
    if (childrenLength > 0) {                                           \
        int i;                                                          \
        for (i = 0; i < childrenLength; i++) {                          \
            nativeWidget = (GtkWidget*)g_list_nth_data(list, i);        \
            widget = makeBaseObjectClass(env, nativeWidget);            \
            if (array == NULL)                                          \
                array = (*env)->NewObjectArray(env, childrenLength,     \
                                               widgetCls, widget);      \
            else                                                        \
                (*env)->SetObjectArrayElement(env, array, i, widget);   \
        }                                                               \
    }                                                                   \
    $CLEANUP        \
    return array;
GList.rawType:      GList *

This mechanism makes it very simple to extend the capabilities 
of the generator by defining new scheme types and adding the 
appropriate code in this text file.


3) Subject:  parent missing from GtkWidget
This has been fixed and is also in cvs.  I will explain how I
fixed this problem and also introduce you to another feature of
the generator.  The generator is far from perfect at this time.
There are many instances when the generator is unable to generate
the appropriate code.  To get around this I added the ability to
insert manual code into the generated code.  In the src/code 
directory you will find two additional directories; java and glue.  T
These directories are where you should place manual code.  The
code found in these files will be inserted into the end for the
code generated by the code generator.  I added the file GtkWidget.java
to the java directory and GtkWidget.h and GtkWidget.c to the glue
directory.  These files contain the fix to you reported problem.


4) Subject:  parent missing from GtkWidget - 
> But what I can't quite figure out is why the java objects are
> created as GtkWidgets instead of being just returned as GtkWidgets.
This is a very good point.  I have been meaning to make this change
but it hasn't been my highest priority.  I have just added a method
to BaseObject called makeBaseObjectClass.  This method detects the
correct Gtk type and builds a peer for it much the same way as
the makeBaseObjectSubclass.  I will be updating the code generator
to use this method where appropriate over the next few days.

I hope I have answered you questions and addressed all of you
issues.  If not please let me know.

-Jeff

Re: [Java-gnome-developer] parent missing from GtkWidget

[Julian F. <jul...@be...>]

But what I can't quite figure out is why the java objects are created as=
 GtkWidgets instead of being just returned as GtkWidgets.

For example, even something like parents() which should return a=
 GtkContainer should actually create a GtkList but then return it as a=
 GtkContainer.  My patch to GtkContainer::children() included code that got=
 the Gtk type, generated the java path for it, and created an object of=
 that type.  But unfortunately I don't understand the code base as a whole=
 well enough to figure out where and if this could be used.  I did try=
 adding the code to GtkWidget::parents() but it seemed to cause other=
 problems there and I gave up.

But I can't see any fundamental reason why it wouldn't work.  I've run into=
 3 or 4 cases already where an object is not being created as the=
 appropriate subclass and I've had to modify the generated code to fix it.=
  Obviously I'd like to fix the fundamental problem instead.  On the other=
 hand the project I'm using it in is almost done so maybe Gtk 2.0 will be=
 stable by the time I need it again.

Julian

On 26/03/01 at 11:24 AM Dan Bornstein wrote:

>Julian Fitzell writes:
>>Also, is there some reason why so many methods return GtkWidgets instead
>of
>>what the C versions return?
>
>There's a reason, but not a particularly good one. The bulk of the .defs
>files comes from the gtk distribution, and *they* weren't particularly
>consistent. Java-Gnome inherited that inconsistency.
>
>The good news is that with gtk-2.0, a lot of the language binding issues=
 go
>away and the whole thing can become a lot cleaner. The bad news is I have
>no idea when 2.0 will be stable enough to develop against.
>
>-dan
>
>_______________________________________________
>java-gnome-developer mailing list
>jav...@li...
>http://lists.sourceforge.net/lists/listinfo/java-gnome-developer

Re: [Java-gnome-developer] parent missing from GtkWidget

[Dan B. <da...@mi...>]

Julian Fitzell writes:
>Also, is there some reason why so many methods return GtkWidgets instead of
>what the C versions return?

There's a reason, but not a particularly good one. The bulk of the .defs
files comes from the gtk distribution, and *they* weren't particularly
consistent. Java-Gnome inherited that inconsistency.

The good news is that with gtk-2.0, a lot of the language binding issues go
away and the whole thing can become a lot cleaner. The bad news is I have
no idea when 2.0 will be stable enough to develop against.

-dan

Re: [Java-gnome-developer] parent missing from GtkWidget

[Julian F. <jul...@be...>]

Argh... forget this one... I originally had (GtkWidget parent) but then had=
 to change it in code to use GtkContainer.  I then changed the defs file to=
 use GtkContainer but didn't try it before submitting the patch.. of course=
 I find it won't build because GtkContainer isn't defined yet at this=
 point... 

Of course, this doesn't solve the problem that it doesn't work without=
 being a GtkContainer... in fact, it really needs to return a GtkContainer=
 but create an object that is actually of the correct subclass of=
 GtkContainer.  Shouldn't this always be the case?  Shouldn't all the=
 methods create objects of the appropriate type and just return them as a=
 superclass where necessary?

Julian


On 23/03/01 at 11:49 PM Julian Fitzell wrote:

>the parent property of GtkWidget seems to be missing from the .defs
>file...
>any reason for this?
>
>Also, is there some reason why so many methods return GtkWidgets instead=
 of
>what the C versions return?
>
>Julian
>
>A patch should it be necessary:
>
>
>Index: src/defs/gtk.defs
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>RCS file: /cvsroot/java-gnome/java-gnome/src/defs/gtk.defs,v
>retrieving revision 1.22
>diff -u -r1.22 gtk.defs
>--- src/defs/gtk.defs   2001/03/01 17:31:53     1.22
>+++ src/defs/gtk.defs   2001/03/24 07:36:57
>@@ -742,7 +742,8 @@
> 
> (define-object GtkWidget (GtkObject)
>   (fields
>-   (GdkWindow window)))
>+   (GdkWindow window)
>+   (GtkContainer parent)))
> 
> (define-func gtk_widget_get_type
>   GtkType
>
>
>_______________________________________________
>java-gnome-developer mailing list
>jav...@li...
>http://lists.sourceforge.net/lists/listinfo/java-gnome-developer

[Java-gnome-developer] parent missing from GtkWidget

[Julian F. <jfi...@ho...>]

the parent property of GtkWidget seems to be missing from the .defs file...
any reason for this?

Also, is there some reason why so many methods return GtkWidgets instead of
what the C versions return?

Julian

A patch should it be necessary:


Index: src/defs/gtk.defs
===================================================================
RCS file: /cvsroot/java-gnome/java-gnome/src/defs/gtk.defs,v
retrieving revision 1.22
diff -u -r1.22 gtk.defs
--- src/defs/gtk.defs   2001/03/01 17:31:53     1.22
+++ src/defs/gtk.defs   2001/03/24 07:36:57
@@ -742,7 +742,8 @@
 
 (define-object GtkWidget (GtkObject)
   (fields
-   (GdkWindow window)))
+   (GdkWindow window)
+   (GtkContainer parent)))
 
 (define-func gtk_widget_get_type
   GtkType

[Java-gnome-developer] Freezing on runtime exception within signal handler

[Julian F. <jfi...@ho...>]

When a runtime exception (such as a NullPointerException) gets thrown from
within a handler method, the entire Gtk main loop freezes.

This patch corrects the problem.  The only thing is it seems like the
exception may not be getting re-thrown like it ought to be... the program
no longer freezes but the main loop doesn't exit with an exception either.
Anyway, it's one step up from where it was:

Julian

Index: src/other/callback_dispatcher.c
===================================================================
RCS file: /cvsroot/java-gnome/java-gnome/src/other/callback_dispatcher.c,v
retrieving revision 1.14
diff -u -r1.14 callback_dispatcher.c
--- src/other/callback_dispatcher.c     2001/03/15 12:34:24     1.14
+++ src/other/callback_dispatcher.c     2001/03/24 06:57:10
@@ -118,6 +118,7 @@
     jobject globalObj;
     jlong peer;
     jfieldID peerfid;
+    jthrowable exc;
     
     jargs = alloca(n_args+1 * sizeof(jvalue));
 
@@ -251,6 +252,12 @@
     default:
       printf("*** ERROR ***:  Return type %d NYI", args[n_args].type);
       break;
+    }
+
+    exc = (* cbi->env)->ExceptionOccurred(cbi->env);
+    if (exc) {
+       (* cbi->env)->Throw(cbi->env, exc);
+       (* cbi->env)->ExceptionClear(cbi->env);
     }
 }

[Java-gnome-developer] GtkContainer::children()

[Julian F. <jfi...@ho...>]

I needed to use the children() method of GtkContainer but the code being
generated returned a GStringList and it was set to null.

Because we needed it, we wrote the method but I don't even know where to
being trying to fix the generator so it generates appropriate code and I
don't think I have the spare time to figure it out.  I thought I'd include
our code in case it helps you to have something to model off of or
something.

I'm not 100% sure of the Signature in the comment block... my understanding
is a GtkWidget[] has the same type as a GtkWidget but...

Julian

------------snip------------------

    /*
     * Class:     gnu.gtk.GtkContainer
     * Method:    children
     * Signature: ()Lgnu/gtk/GtkWidget;
     */
    JNIEXPORT jobjectArray JNICALL Java_gnu_gtk_GtkContainer_children
(JNIEnv 
        *env, jobject obj) 
    {
        GtkContainer *cptr = peerOfBaseObject (env, obj);
        GList* children = gtk_container_children (cptr);
        int childrenLength = g_list_length(children);
        jclass widget_cls = (*env)->FindClass(env, "gnu/gtk/GtkWidget");

        jobjectArray array;
        jclass result_jc;
        jobject widget;
        GtkWidget *native_widget;
        char classname[100];

        if (childrenLength > 0)
          { 
            int i;
            
            native_widget = (GtkWidget*)g_list_nth_data(children, 0);
            sprintf(classname, "gnu/gtk/%s",
gtk_type_name(GTK_OBJECT_TYPE(native_widget)));
            result_jc = (*env)->FindClass (env, classname);
            widget = makeBaseObjectSubclass (env, result_jc,
native_widget);

            array = (*env)->NewObjectArray(env, childrenLength, widget_cls,
widget);

            for (i = 1;i < childrenLength;i++)
            {
              native_widget = (GtkWidget*)g_list_nth_data(children, i);
              sprintf(classname, "gnu/gtk/%s",
gtk_type_name(GTK_OBJECT_TYPE(native_widget)));
              result_jc = (*env)->FindClass (env, classname);
              widget = makeBaseObjectSubclass (env, result_jc,
native_widget);

              (*env)->SetObjectArrayElement(env, array, i, widget);
            }
          }
          return array;
    }

[Java-gnome-developer] Patch for boolean returning signals again

[Julian F. <z2...@ug...>]

Sorry... something messed up the linefeeds on that.  Here it is again...

Hmm... gonna have to attach it.

Reply to me at ju...@be...

Julian

[Java-gnome-developer] Patch for signals that return booleans

[Julian F. <ju...@be...>]

Julian

Index: src/other/callback_dispatcher.c
=================================================================== RCS
file: /cvsroot/java-gnome/java-gnome/src/other/callback_dispatcher.c,v
retrieving revision 1.13 diff -u -r1.13 callback_dispatcher.c ---
src/other/callback_dispatcher.c 2001/03/05 19:32:19 1.13 +++
src/other/callback_dispatcher.c 2001/03/14 01:12:07 @@ -218,17 +218,27 @@
     switch(args[n_args].type) {
     case GTK_TYPE_BOOL:
         if (cbi->isStatic == JNI_FALSE) - GTK_VALUE_BOOL(args[n_args]) =
+ { + gint *retval = GTK_RETLOC_BOOL(args[n_args]); + jboolean jbool; +
jbool =
                 (* cbi->env)->CallBooleanMethodA(cbi->env,
                                                  cbi->obj,
                                                  mid,
                                                  jargs); - else -
GTK_VALUE_BOOL(args[n_args]) = + *retval = (jbool == JNI_TRUE); + } + else
+ { + gint *retval = GTK_RETLOC_BOOL(args[n_args]); + jboolean jbool; +
jbool =
                 (* cbi->env)->CallStaticBooleanMethodA(cbi->env,
                                                        cbi->class,
                                                        mid,
                                                        jargs); + *retval
= (jbool == JNI_TRUE); + }
         break;
     case GTK_TYPE_NONE:
         if (cbi->isStatic == JNI_FALSE)  

RE: [Java-gnome-developer] java-gtk for Windows?

[Jeff M. <ku...@ne...>]

To my knowledget there has been no attempt to compile java-gnome
on a Windows platform.  If somebody would like to give this a 
try I would welcome the outcome.

> 
> I use the Gimp in Windows
> http://user.sgic.fi/~tml/gimp/win32/downloads.html where were created
> DLLs for running the Gimp.
> I have no C compiler for Windows but I like Java and GTK+.
> Question: Does anybody have compiled the JNI GTK+ code to DLLs in order
> one can make Java-GTK+ applications in Windows?
> Thanks in advance.
> ...by the way I heard GNOME was ported to Windows too...
> 

-Jeff

Re: [Java-gnome-developer] java-gtk for Windows?

[Ian D . S. <ids...@so...>]

On 2001.03.05 17:03:54 -0500 Jorge Mireles J. wrote:
> I use the Gimp in Windows
> http://user.sgic.fi/~tml/gimp/win32/downloads.html where were created
> DLLs for running the Gimp.
> I have no C compiler for Windows but I like Java and GTK+.

Hey Jorge,

GTK+ has successfullu been built on Windows using the MinGW toolset.  You
may be able to build java-gtk by yourself.

Check out http://mingw.sourceforge.net/ for more details.


HTH,
Ian

[Java-gnome-developer] java-gtk for Windows?

[Jorge M. J. <jmi...@se...>]

I use the Gimp in Windows
http://user.sgic.fi/~tml/gimp/win32/downloads.html where were created
DLLs for running the Gimp.
I have no C compiler for Windows but I like Java and GTK+.
Question: Does anybody have compiled the JNI GTK+ code to DLLs in order
one can make Java-GTK+ applications in Windows?
Thanks in advance.
...by the way I heard GNOME was ported to Windows too...

Re: [Java-gnome-developer] I'd like to work on an AWT binding

[Ian D . S. <ids...@so...>]

On 2001.03.03 09:46:07 -0500 John Stracke wrote:
> I'm interested in building a set of AWT peers on top of java-gnome, so 
> that I can have AWT-based apps look right on my desktop.  Is anybody 
> already working on such a thing?

I don't know of anybody working on AWT peers for GNOME, but the good folks
at ClassPath have developed a GTK+ AWT implementation.  If it doesn't do
what you want, it should at least get you started in the right direction.

See:
	http://www.gnu.org/software/classpath/status.html#java.awt
	http://subversions.gnu.org/cgi-bin/cvsweb/classpath/gnu/java/awt/


HTH,
Ian

[Java-gnome-developer] I'd like to work on an AWT binding

[John S. <fr...@th...>]

I'm interested in building a set of AWT peers on top of java-gnome, so 
that I can have AWT-based apps look right on my desktop.  Is anybody 
already working on such a thing?

-- 
/==============================================================\
|John Stracke        | http://www.thibault.org |HTML OK        |
|Francois Thibault   |=========================================|
|East Kingdom        |I am Homer of Borg. Prepare to be assi...|
|fr...@th...|Mmm, doughnuts!                          |
\==============================================================/

[Java-gnome-developer] GtkCTree support added

[Morgan, J. <Jef...@rp...>]

A while back I got an email from somebody asking when 
support for GtkCTree will be added to java-gnome.  I have
just checked in support for this widget to cvs.  I also included
a simple example in src/examples/gtk/ctree.  Over the
next week I hope to enhance the implementation.

-Jeff

[Java-gnome-developer] Java-GNOME 0.6 release

[Morgan, J. <Jef...@rp...>]

We are pleased to announce a new release of the Java-GNOME bindings.
There has been an enormous amount of work that has gone into this release. 
A few of the enhancements are as follows:

1) The parser/code generator has been rewritten to add enhanced flexibility
and 
granularity to the generated code. 
2) Support has been added for numerous new widgets from GDK, GTK and 
libgnomeui. 
3) Most of the capabilities found in libgnome have been incorporated into
the 
bindings including gnome-sound, gnome-config, gnome- url, and gnome-exec. 
4) Support for libglade has been added. 
5) The callback mechanism has also been enhanced. 
6) The documentation has been updated including the additional of two new 
chapters in the tutorial. 
7) 47 examples are now included to demonstrate many of the capabilities
found 
in the bindings. 

We are very proud of this release and look forward to your feedback. 

-Jeff

Re: [Java-gnome-developer] Re: Question and Introduction

[Josh L. <jo...@st...>]

"Morgan, Jeffrey" wrote:
> 
> Josh,
> 
> Thanks for your nice comments and input.  The bug you experienced has
> been addressed and the fix is in CVS.  You asked about the overall
> status of the bindings.  The binding is reaching a point of being very
> functional.  This release (0.6) is a major step forward as far as
> stability and functionality.  If you haven't done so, I would strongly
> recommend getting the latest copy from cvs.
> 
> The tutorial has been updated with several new chapters and a
> rewrite of the old chapters to include new capabilities.  There are
> also numerous new examples that can be used to introduce you
> to various aspects of the library.
> 
> We would welcome you to the team if you are interested in joining.
> At this point, all that remains to complete for the new build is
> creating the distributions (rpms, tars, etc), testing the distros,
> updating the web site, and making all of the appropriate
> announcements.  I believe these tasks are already assigned and
> should be completed within the next 1-2 days.
> 
> Going forward we hope to have new releases every 4 - 8 weeks
> and have proposed the next few releases to the user base with
> little feedback.  You can find the proposal for the next releases
> at http://www.geocrawler.com/lists/3/SourceForge/7036/0/5214277/.
> 
> If you are interested in joining the team the first step would be
> to look at how we generate the code and look at the examples.
> If you want to contribute, let me know.  It would help to have an
> understanding of your skills.  Do you know java, JNI, or C?
> Finally, you will need to be a sourceforge registered developer.
> At that point I could add you to the developers list, which
> would give you CVS update capability.
> 
> I do look forward to hearing from you.
> 

Jeff (and Jean) -

Hopefully this response will answer both emails..  :)

I have checked out the latest from CVS and that bug is definitely not
there now.  Cool!

As far as my experience/involvement goes, I wear two hats at my day job,
that of java developer and release engineer.  Obviously, I am most
comfortable in writing Java code but I've also written C and used JNI to
integrate that into other java apps.

I am hoping to contribute as I really like the idea of using Java for
GNOME development.  I will start looking through the generation and
examples and start asking questions.. :)


josh

[Java-gnome-developer] Re: GtkContainer.children()

[Morgan, J. <Jef...@rp...>]

Julian,

We are just a day or two away from the next release of the bindings.
Are you experiencing this problem in the code currently in CVS?
If not, I recommend getting the latest sources from CVS as this
bug might already be fixed.  If this bug currently exists in CVS,
please submit a bug report to:

http://sourceforge.net/tracker/?group_id=1522&atid=101522


I will try to take a look at the problem once the next release is
out.

Thanks
-Jeff

[Java-gnome-developer] Re: Question and Introduction

[Morgan, J. <Jef...@rp...>]

Josh,

Thanks for your nice comments and input.  The bug you experienced has 
been addressed and the fix is in CVS.  You asked about the overall
status of the bindings.  The binding is reaching a point of being very
functional.  This release (0.6) is a major step forward as far as 
stability and functionality.  If you haven't done so, I would strongly
recommend getting the latest copy from cvs.

The tutorial has been updated with several new chapters and a
rewrite of the old chapters to include new capabilities.  There are
also numerous new examples that can be used to introduce you
to various aspects of the library.

We would welcome you to the team if you are interested in joining.
At this point, all that remains to complete for the new build is
creating the distributions (rpms, tars, etc), testing the distros,
updating the web site, and making all of the appropriate
announcements.  I believe these tasks are already assigned and
should be completed within the next 1-2 days.

Going forward we hope to have new releases every 4 - 8 weeks 
and have proposed the next few releases to the user base with
little feedback.  You can find the proposal for the next releases
at http://www.geocrawler.com/lists/3/SourceForge/7036/0/5214277/.

If you are interested in joining the team the first step would be 
to look at how we generate the code and look at the examples.
If you want to contribute, let me know.  It would help to have an
understanding of your skills.  Do you know java, JNI, or C?
Finally, you will need to be a sourceforge registered developer.
At that point I could add you to the developers list, which 
would give you CVS update capability.

I do look forward to hearing from you.

-Jeff

Re: [Java-gnome-developer] Question and Introduction

[Jean v. W. <je...@sm...>]

Hi Josh,

On Mon, 26 Feb 2001, Josh Lucas wrote:

> Hi -
> 
> I just subscribed to the list and actually just built the code and ran
> the TestGNOME class.  Very cool!

Thank you very much.

> I had one hiccup during the build but it seems it was more of an issue
> with the jni.h file supplied with the jdk.  I'm using the Sun 1.3 JDK
> and the jni.h file tries to include a jni_md.h but the file is actually
> in include/linux instead of just include.  A quick path change in the
> file made everything build.

That is one of the changes that we made.  Now it will only do that for a
JDK 1.1.  With a JDK > 1.3.0 it only needs to include one file.  You can
check it out in the CVS code.  (By the way the configure script / Makefiles
was re-written totally.)

> My question is to overall status.  I went through the archives a bit and
> there seemed to be a bit of discussion about a release happening soon. 
> Is that still the case?  Is there anything I could do to help as a way
> of getting my hands dirty and looking through the code?

Well we hope to do it tomorow / later in the week and then make an
anouncement after some testing.  We have quite a bit of new code in the 0.6
release.  We have some support for libglade / libglade-gnome as well, so
you may look forward to a new interesting and more feature complete
version.

We would appreciate your help.  We do not know what your core capabilities
are and interests are so we prefer that yoy tell us in which area you would
like to be working (with some guidance as to what needs to be done of
course).  You are welcome to help us if you can.  We may only assign some
tasks after the release but for now you can check out the code from CVS and
compile it to see whether you have some ideas.

Some areas where we always like some more help is in writing some examples
/ tests and documentation. We are slowly moving from large examples like
those in test to smaller examples in src/examples.  They are easier to
expand more focussed and easier to understand.

> thanks,
> josh

Looking forward to your help / suggestions.

Regards
Jean

[Java-gnome-developer] GtkContainer.children()

[Julian F. <jul...@be...>]

Anyone know why this always returns null?

Julian Fitzell

[Java-gnome-developer] Question and Introduction

[Josh L. <jo...@st...>]

Hi -

I just subscribed to the list and actually just built the code and ran
the TestGNOME class.  Very cool!

I had one hiccup during the build but it seems it was more of an issue
with the jni.h file supplied with the jdk.  I'm using the Sun 1.3 JDK
and the jni.h file tries to include a jni_md.h but the file is actually
in include/linux instead of just include.  A quick path change in the
file made everything build.

My question is to overall status.  I went through the archives a bit and
there seemed to be a bit of discussion about a release happening soon. 
Is that still the case?  Is there anything I could do to help as a way
of getting my hands dirty and looking through the code?


thanks,
josh