Re: [Java-gnome-developer] Julian's contributions
Brought to you by:
afcowie
Menu
▾
▴
Re: [Java-gnome-developer] Julian's contributions
|
From: Julian F. <jul...@be...> - 2001-03-30 03:02:12
|
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
|
