java-gnome-hackers — Hacking on the bindings themselves: design issues and co-ordination

Re: [java-gnome-hackers] Debugging Native code

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

Debugging the native code is not that simple.  You will need the
source code for the libraries you wish to debug and the code
needs to match the installed apps.

What I usually do is set a breakpoint in the java code immediately
after the native library is loaded.  Then you can use a debugger
(gdb, ddd, or eclipse) to attach to the running shared object.  
Once this is done place a breakpoint in the C code at the place you
wish to debug.

Perhaps I can have a look today.

-Jeff 

On Fri, 2002-08-30 at 19:56, Philip A. Chapman wrote:
> Jeff,
> 
> I'm having issues with the TestGNOME application.  The first button
> creates an About object instance and shows it.  By putting
> System.out.println()'s in About.java, I've determined that the code is
> hanging in the call to java_about_new in org_gnu_gnome_About.c. 
> Therefore, I need to do some debugging in the native code to determine
> what's happening.
> 
> I'm about to install eclipse in hopes that it has good debugging into
> jni calls.  If you have any tips or tricks you've picked up on how to
> debug jni calls, I'd appreciate them.
> 
> It appears that the other classes the TestGNOME application have similar
> problem too.
> 
> I wanted to install eclipse anyway, but haven't taken the time until
> now.  :-)
> -- 
> Philip A. Chapman

[java-gnome-hackers] Debugging Native code

[Philip A. C. <pc...@td...>]

Jeff,

I'm having issues with the TestGNOME application.  The first button
creates an About object instance and shows it.  By putting
System.out.println()'s in About.java, I've determined that the code is
hanging in the call to java_about_new in org_gnu_gnome_About.c. 
Therefore, I need to do some debugging in the native code to determine
what's happening.

I'm about to install eclipse in hopes that it has good debugging into
jni calls.  If you have any tips or tricks you've picked up on how to
debug jni calls, I'd appreciate them.

It appears that the other classes the TestGNOME application have similar
problem too.

I wanted to install eclipse anyway, but haven't taken the time until
now.  :-)
-- 
Philip A. Chapman

Re: [java-gnome-hackers] free software; Debian packages

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

ToolBar no longer uses classes from sun.awt.

On Fri, 2002-08-30 at 16:07, Mark Howard wrote:
> Hi,
>   I've been working on Debian packages for java-gnome. I've been trying
> to keep this in the main Debian section but have been having trouble:
> 
> * Ant is in contrib -> I've made makefile replacements
> 
> * A number of packages rely on sun.awt. AFAIK, this is not implemented
> in any of the free java implementations (gcj doesn't seem to work).
> please correct me if I'm wrong.
> The affected classes are:
> gdk/WindowAttr.java
> gdk/Drawable.java
> gdk/Gdk.java
> gtk/ToolBar.java
> 
> How difficult would it be to change these so that they don't use awt?
> (possibly create replacements for the awt classes)
> 
> I think one of the main reasons many people would choose java-gnome over
> swing is that it is truly free software, hence these changes are
> important. If java-gnome can't be compiled with one of the free
> compilers, then it wouldn't be classed as Free software in Debian terms,
> would not be allowed into the main archive and hence would not appear on
> official DVDs or CDs. Furthermore, it would not be able to take
> advantage of the build daemons, which try to create and test packages on
> 15 (I think) architecture/OS combinations. Also, packages using
> java-gnome would not be allowed into the main distribution.
> -- 
> 
> +----------------------------------------------+
> | Mark Howard               cam.ac.uk   mh344@ |
> | http://www.tildemh.com    tildemh.com    mh@ |
> +----------------------------------------------+

Re: [java-gnome-hackers] free software; Debian packages

[Sergio R. <ser...@hi...>]

Yea, ok. I think this can be changed without problems. I think that the
only class I use is the Dimension class. I'll have a look at it.

bye!


On Fri, 2002-08-30 at 22:07, Mark Howard wrote:
> Hi,
>   I've been working on Debian packages for java-gnome. I've been trying
> to keep this in the main Debian section but have been having trouble:
> 
> * Ant is in contrib -> I've made makefile replacements
> 
> * A number of packages rely on sun.awt. AFAIK, this is not implemented
> in any of the free java implementations (gcj doesn't seem to work).
> please correct me if I'm wrong.
> The affected classes are:
> gdk/WindowAttr.java
> gdk/Drawable.java
> gdk/Gdk.java
> gtk/ToolBar.java
> 
> How difficult would it be to change these so that they don't use awt?
> (possibly create replacements for the awt classes)
> 
> I think one of the main reasons many people would choose java-gnome over
> swing is that it is truly free software, hence these changes are
> important. If java-gnome can't be compiled with one of the free
> compilers, then it wouldn't be classed as Free software in Debian terms,
> would not be allowed into the main archive and hence would not appear on
> official DVDs or CDs. Furthermore, it would not be able to take
> advantage of the build daemons, which try to create and test packages on
> 15 (I think) architecture/OS combinations. Also, packages using
> java-gnome would not be allowed into the main distribution.
> -- 
> 
> +----------------------------------------------+
> | Mark Howard               cam.ac.uk   mh344@ |
> | http://www.tildemh.com    tildemh.com    mh@ |
> +----------------------------------------------+

[java-gnome-hackers] free software; Debian packages

[Mark H. <mh...@ti...>]

Hi,
  I've been working on Debian packages for java-gnome. I've been trying
to keep this in the main Debian section but have been having trouble:

* Ant is in contrib -> I've made makefile replacements

* A number of packages rely on sun.awt. AFAIK, this is not implemented
in any of the free java implementations (gcj doesn't seem to work).
please correct me if I'm wrong.
The affected classes are:
gdk/WindowAttr.java
gdk/Drawable.java
gdk/Gdk.java
gtk/ToolBar.java

How difficult would it be to change these so that they don't use awt?
(possibly create replacements for the awt classes)

I think one of the main reasons many people would choose java-gnome over
swing is that it is truly free software, hence these changes are
important. If java-gnome can't be compiled with one of the free
compilers, then it wouldn't be classed as Free software in Debian terms,
would not be allowed into the main archive and hence would not appear on
official DVDs or CDs. Furthermore, it would not be able to take
advantage of the build daemons, which try to create and test packages on
15 (I think) architecture/OS combinations. Also, packages using
java-gnome would not be allowed into the main distribution.
--=20

+----------------------------------------------+
| Mark Howard               cam.ac.uk   mh344@ |
| http://www.tildemh.com    tildemh.com    mh@ |
+----------------------------------------------+

RE: [java-gnome-hackers] Tree/List widgets

[Mark H. <mh...@ti...>]

On Fri, 2002-08-30 at 12:24, Jeffrey Morgan wrote:
> I just checked some code into cvs that I think should resolve
> this issue.  I don't have a test case to verify if it works.
> Are you in a position to test this method?

My original test is in src/examples/gtk/tree/TreeExample.java
(it's actually a list example, but that's not important)

I'm now getting a different error:
(java-gnome:2091): Gtk-CRITICAL **: file gtkliststore.c: line 1294
(gtk_list_store_append): assertion `iter !=3D NULL' failed

(java-gnome:2091): GLib-GObject-WARNING **: gvalue.c:86:g_value_init():
cannot initialize GValue with type `(null)', the value has already been
initialized as `(null)'
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=3D0x49df27d2
Function name=3Dg_type_check_value_holds
Library=3D/usr/lib/libgobject-2.0.so.0

Current Java thread:
	at org.gnu.glib.Value.g_value_set_string(Native Method)
	at org.gnu.glib.Value.setString(Value.java:55)
	at tree.TreeExample.<init>(TreeExample.java:35)
	at tree.TreeExample.main(TreeExample.java:48)

It's the same line, but looks like a problem with glib.Type this time.=20

--=20

+----------------------------------------------+
| Mark Howard               cam.ac.uk   mh344@ |
| http://www.tildemh.com    tildemh.com    mh@ |
+----------------------------------------------+

RE: [java-gnome-hackers] Tree/List widgets

[Jeffrey M. <Jef...@Br...>]

I just checked some code into cvs that I think should resolve
this issue.  I don't have a test case to verify if it works.
Are you in a position to test this method?

-Jeff

> On Sat, 2002-08-24 at 14:35, Jeffrey Morgan wrote:
> > I will look into this over the weekend.
> 
> did you get anywhere with this?
> 
> or has anybody else got any ideas?
> 
> > 
> > On Sat, 2002-08-24 at 06:00, Mark Howard wrote:
> > > On Fri, 2002-08-23 at 17:46, Mark Howard wrote:
> > > > public Value(Type type) {
> > > > 		int [] vptr = new int[1];
> > > > 		Value.g_value_init(vptr, type.getHandle());
> > > > 		handle = vptr[0];
> > > > }
> > > 
> > > Has anyone successfully used the glib.Value object? 
> > > 
> > > The gtk reference says:
> > > GValue*     g_value_init                    (GValue *value,
> > >                                              GType g_type);
> > > Initializes value with the default value of type.
> > > value : A zero-filled (uninitialized) GValue structure.
> > > g_type : Type the GValue should hold values of.
> > > Returns :  <no comment>
> > > 
> > > 
> > > The JNI code, however, uses the return statement:
> > > /*
> > >  * Class:     org.gnu.glib.Value
> > >  * Method:    g_value_init
> > >  * Signature: ([Lint ;I)I
> > >  */
> > > JNIEXPORT jint JNICALL 
> Java_org_gnu_glib_Value_g_1value_1init (JNIEnv
> > > *env, jclass cls, 
> > >     jintArray value, jint type) 
> > > {
> > >     gint *value_g_g = (gint *) 
> (*env)->GetIntArrayElements (env, value,
> > > NULL);
> > >     GValue *value_g = (GValue *)value_g_g;
> > >     GType type_g = (GType)&type;
> > >     {
> > >         return (jint)g_value_init (value_g, type_g);
> > >     }
> > > }
> > > 
> > > 
> > > Although this return value is ignored in the java code:
> > > /**
> > >  * Construct a new Value from a given org.gnu.glib.Value.
> > >  */
> > > public Value(Type type) {
> > > 	int [] vptr = new int[1];
> > > 	Value.g_value_init(vptr, type.getHandle());
> > > 	handle = vptr[0];
> > > }
> > > 
> > > Could someone who knows more about this please check it and either
> > > confirm that the Value code is correct or try to fix it.
> > > 
> > > Thanks
> > > -- 
> 
> -- 
> 
> +----------------------------------------------+
> | Mark Howard               cam.ac.uk   mh344@ |
> | http://www.tildemh.com    tildemh.com    mh@ |
> +----------------------------------------------+
> 

RE: [java-gnome-hackers] Tree/List widgets

[Jeffrey M. <Jef...@Br...>]

I will look at it now.

-Jeff


> On Sat, 2002-08-24 at 14:35, Jeffrey Morgan wrote:
> > I will look into this over the weekend.
> 
> did you get anywhere with this?
> 
> or has anybody else got any ideas?
> 
> > 
> > On Sat, 2002-08-24 at 06:00, Mark Howard wrote:
> > > On Fri, 2002-08-23 at 17:46, Mark Howard wrote:
> > > > public Value(Type type) {
> > > > 		int [] vptr = new int[1];
> > > > 		Value.g_value_init(vptr, type.getHandle());
> > > > 		handle = vptr[0];
> > > > }
> > > 
> > > Has anyone successfully used the glib.Value object? 
> > > 
> > > The gtk reference says:
> > > GValue*     g_value_init                    (GValue *value,
> > >                                              GType g_type);
> > > Initializes value with the default value of type.
> > > value : A zero-filled (uninitialized) GValue structure.
> > > g_type : Type the GValue should hold values of.
> > > Returns :  <no comment>
> > > 
> > > 
> > > The JNI code, however, uses the return statement:
> > > /*
> > >  * Class:     org.gnu.glib.Value
> > >  * Method:    g_value_init
> > >  * Signature: ([Lint ;I)I
> > >  */
> > > JNIEXPORT jint JNICALL 
> Java_org_gnu_glib_Value_g_1value_1init (JNIEnv
> > > *env, jclass cls, 
> > >     jintArray value, jint type) 
> > > {
> > >     gint *value_g_g = (gint *) 
> (*env)->GetIntArrayElements (env, value,
> > > NULL);
> > >     GValue *value_g = (GValue *)value_g_g;
> > >     GType type_g = (GType)&type;
> > >     {
> > >         return (jint)g_value_init (value_g, type_g);
> > >     }
> > > }
> > > 
> > > 
> > > Although this return value is ignored in the java code:
> > > /**
> > >  * Construct a new Value from a given org.gnu.glib.Value.
> > >  */
> > > public Value(Type type) {
> > > 	int [] vptr = new int[1];
> > > 	Value.g_value_init(vptr, type.getHandle());
> > > 	handle = vptr[0];
> > > }
> > > 
> > > Could someone who knows more about this please check it and either
> > > confirm that the Value code is correct or try to fix it.
> > > 
> > > Thanks
> > > -- 
> 
> -- 
> 
> +----------------------------------------------+
> | Mark Howard               cam.ac.uk   mh344@ |
> | http://www.tildemh.com    tildemh.com    mh@ |
> +----------------------------------------------+
> 

Re: [java-gnome-hackers] Tree/List widgets

[Mark H. <mh...@ti...>]

On Sat, 2002-08-24 at 14:35, Jeffrey Morgan wrote:
> I will look into this over the weekend.

did you get anywhere with this?

or has anybody else got any ideas?

>=20
> On Sat, 2002-08-24 at 06:00, Mark Howard wrote:
> > On Fri, 2002-08-23 at 17:46, Mark Howard wrote:
> > > public Value(Type type) {
> > > 		int [] vptr =3D new int[1];
> > > 		Value.g_value_init(vptr, type.getHandle());
> > > 		handle =3D vptr[0];
> > > }
> >=20
> > Has anyone successfully used the glib.Value object?=20
> >=20
> > The gtk reference says:
> > GValue*     g_value_init                    (GValue *value,
> >                                              GType g_type);
> > Initializes value with the default value of type.
> > value : A zero-filled (uninitialized) GValue structure.
> > g_type : Type the GValue should hold values of.
> > Returns :  <no comment>
> >=20
> >=20
> > The JNI code, however, uses the return statement:
> > /*
> >  * Class:     org.gnu.glib.Value
> >  * Method:    g_value_init
> >  * Signature: ([Lint ;I)I
> >  */
> > JNIEXPORT jint JNICALL Java_org_gnu_glib_Value_g_1value_1init (JNIEnv
> > *env, jclass cls,=20
> >     jintArray value, jint type)=20
> > {
> >     gint *value_g_g =3D (gint *) (*env)->GetIntArrayElements (env, valu=
e,
> > NULL);
> >     GValue *value_g =3D (GValue *)value_g_g;
> >     GType type_g =3D (GType)&type;
> >     {
> >         return (jint)g_value_init (value_g, type_g);
> >     }
> > }
> >=20
> >=20
> > Although this return value is ignored in the java code:
> > /**
> >  * Construct a new Value from a given org.gnu.glib.Value.
> >  */
> > public Value(Type type) {
> > 	int [] vptr =3D new int[1];
> > 	Value.g_value_init(vptr, type.getHandle());
> > 	handle =3D vptr[0];
> > }
> >=20
> > Could someone who knows more about this please check it and either
> > confirm that the Value code is correct or try to fix it.
> >=20
> > Thanks
> > --=20

--=20

+----------------------------------------------+
| Mark Howard               cam.ac.uk   mh344@ |
| http://www.tildemh.com    tildemh.com    mh@ |
+----------------------------------------------+

RE: [java-gnome-hackers] App.setStatusBar

[Jeffrey M. <Jef...@Br...>]

> While working to get TestGNOME.java working, I came across 
> this issue. 
> In TestGNOME, an org.gnu.gtk.AppBar is created.  An attempt is made to
> assign it to org.gnu.gnome.App.setStatusBar(org.gnu.gnome.StatusBar). 
> Right now, StatusBar does not extend AppBar.  In gnome-app.h,
> gnome_app_set_statusbar takes a pointer to GtkWidget.  Could 
> a developer
> pass *any* widget to this function?
> 
> My first inclination is to overload setStatusBar with
> setStatusBar(org.gnu.gtk.AppBar) as well as
> setStatusBar(org.gnu.gnome.StatusBar).

Both GtkStatusbar and GnomeAppbar extend from GtkHBox.  Internally,
once you pass the object to the set_statusbar method it casts it
to a GtkWidget and just adds it to the container.  I think the
overloaded method is the best approach.  You should be able to
pass either handle to the method and expect it to work fine.

> I've tried using
> http://developer.gnome.org/doc/API/libgnomeui/gnomeapp.html 
> for insight,
> into how the gnome_app_set_statusbar function should be used. 
> Unfortunately, I could find nothing there to help me with this.  Is
> there a better place to look?  If the only answer is to view the gnome
> source I will go there, but I'd rather not.

The best approach is to look at the docs first.  If it doesn't answer
the question then post to this list.  I am fairly familiar with the
code for both gtk and libgnomeui and can usually derive an answer
quickly.

-Jeff

Re: [java-gnome-hackers] App.setStatusBar

[Sergio R. <ser...@hi...>]

Hi,

I think that if the gnome statusbar represents the same as the gtk
appbar, the gnome guys should have extended the gtk appbar, since
gnomeui is built on top of gtk. Anyway, IMHO working with gnome stuff,
seems to be redundant using two types of statusbar in an application. In
case that gnome statusbar extends from gtk appbar I think that the
approach of writting a method that supports the gtk appbar should be the
correct one.

I had never worked with gnome or gtk before, so sure I'm not helping you
too much. Sorry.



On Wed, 2002-08-28 at 05:48, Philip A. Chapman wrote:
> Everyone,
> 
> This is more of a "How does this work in gnome" issue than anything
> else, but here goes:
> 
> While working to get TestGNOME.java working, I came across this issue. 
> In TestGNOME, an org.gnu.gtk.AppBar is created.  An attempt is made to
> assign it to org.gnu.gnome.App.setStatusBar(org.gnu.gnome.StatusBar). 
> Right now, StatusBar does not extend AppBar.  In gnome-app.h,
> gnome_app_set_statusbar takes a pointer to GtkWidget.  Could a developer
> pass *any* widget to this function?
> 
> My first inclination is to overload setStatusBar with
> setStatusBar(org.gnu.gtk.AppBar) as well as
> setStatusBar(org.gnu.gnome.StatusBar).
> 
> Alternatively, I could change to setStatusBar(org.gnu.gtk.Widget), or
> change StatusBar so that it extends AppBar.  I'm a fan of strong typing
> and would rather not change the method.  Extending AppBar may be an
> issue, since gnome's status bar doesn't extend from gtk's app bar.
> 
> I've tried using
> http://developer.gnome.org/doc/API/libgnomeui/gnomeapp.html for insight,
> into how the gnome_app_set_statusbar function should be used. 
> Unfortunately, I could find nothing there to help me with this.  Is
> there a better place to look?  If the only answer is to view the gnome
> source I will go there, but I'd rather not.
> 
> Thanks,
> -- 
> Philip A. Chapman

[java-gnome-hackers] App.setStatusBar

[Philip A. C. <pc...@td...>]

Everyone,

This is more of a "How does this work in gnome" issue than anything
else, but here goes:

While working to get TestGNOME.java working, I came across this issue.=20
In TestGNOME, an org.gnu.gtk.AppBar is created.  An attempt is made to
assign it to org.gnu.gnome.App.setStatusBar(org.gnu.gnome.StatusBar).=20
Right now, StatusBar does not extend AppBar.  In gnome-app.h,
gnome_app_set_statusbar takes a pointer to GtkWidget.  Could a developer
pass *any* widget to this function?

My first inclination is to overload setStatusBar with
setStatusBar(org.gnu.gtk.AppBar) as well as
setStatusBar(org.gnu.gnome.StatusBar).

Alternatively, I could change to setStatusBar(org.gnu.gtk.Widget), or
change StatusBar so that it extends AppBar.  I'm a fan of strong typing
and would rather not change the method.  Extending AppBar may be an
issue, since gnome's status bar doesn't extend from gtk's app bar.

I've tried using
http://developer.gnome.org/doc/API/libgnomeui/gnomeapp.html for insight,
into how the gnome_app_set_statusbar function should be used.=20
Unfortunately, I could find nothing there to help me with this.  Is
there a better place to look?  If the only answer is to view the gnome
source I will go there, but I'd rather not.

Thanks,
--=20
Philip A. Chapman

[java-gnome-hackers] Widget ref and unref

[Mark H. <mh...@ti...>]

hi,
  If a widget is removed from a container, it is destroyed unless there
has been a call to gtk_widget_ref(handle). To get the widget to be
destroyed, a call must be made to gtk_widget_unref(handle);

IMHO, this should not happen in Java - once you construct an object, it
should exist until the java reference to it is lost.=20
Therefore, I have added this code to the Widget class. The ref is made
in the initializeEventHanders method (All widgets should call this in
their constructors); and the unref is done in a finalize method, so it
will be done when java start garbage collecting the object.

I have not found any problems with this in the small amount of testing I
have done.=20

Let me know if there are any objection to this change.

--=20

+----------------------------------------------+
| Mark Howard               cam.ac.uk   mh344@ |
| http://www.tildemh.com    tildemh.com    mh@ |
+----------------------------------------------+

Re: [java-gnome-hackers] StockName class

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

You can change it by hand.  Since there is no native
code you will not need to worry about the C code.

-Jeff


On Mon, 2002-08-26 at 19:26, Sergio Rubio wrote:
> hi,
> 
> Can I change the generated code in the StockName class by hand or should
> del generator be modified and regenerate de code again?
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
> 

[java-gnome-hackers] StockName class

[Sergio R. <ser...@hi...>]

hi,

Can I change the generated code in the StockName class by hand or should
del generator be modified and regenerate de code again?

Re: [java-gnome-hackers] StockNames

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

> well, you could do it all in one line:
> Button b=new Button( new StockName(StockName.SAVE) );
> but you're right, it's probably best to have static objects.
> Also, StockItem might be a better name than StockName.

I agree with both statements.

-Jeff

Re: [java-gnome-hackers] StockNames

[Mark H. <mh...@ti...>]

On Sun, 2002-08-25 at 01:15, Sergio Rubio wrote:
> Hi all!
>=20
> Jeff, don't you think that StockNames should be static StockName
> objects?
>=20
> I mean, if you are going to create a new stock Button ie,
>=20
> Button b=3Dnew Button(StockName.SAVE);
>=20
> you can't do it like this, firts of all you have to build the StockName
> object,
>=20
> StockName obj=3Dnew StockName(StockName.SAVE);
> Button b=3Dnew Button(obj);
>=20
> I this correct?
well, you could do it all in one line:
Button b=3Dnew Button( new StockName(StockName.SAVE) );
but you're right, it's probably best to have static objects.
Also, StockItem might be a better name than StockName.

--=20

+----------------------------------------------+
| Mark Howard               cam.ac.uk   mh344@ |
| http://www.tildemh.com    tildemh.com    mh@ |
+----------------------------------------------+

[java-gnome-hackers] StockNames

[Sergio R. <ser...@hi...>]

Hi all!

Jeff, don't you think that StockNames should be static StockName
objects?

I mean, if you are going to create a new stock Button ie,

Button b=new Button(StockName.SAVE);

you can't do it like this, firts of all you have to build the StockName
object,

StockName obj=new StockName(StockName.SAVE);
Button b=new Button(obj);

I this correct?

Re: [java-gnome-hackers] Tree/List widgets

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

I will look into this over the weekend.

On Sat, 2002-08-24 at 06:00, Mark Howard wrote:
> On Fri, 2002-08-23 at 17:46, Mark Howard wrote:
> > public Value(Type type) {
> > 		int [] vptr = new int[1];
> > 		Value.g_value_init(vptr, type.getHandle());
> > 		handle = vptr[0];
> > }
> 
> Has anyone successfully used the glib.Value object? 
> 
> The gtk reference says:
> GValue*     g_value_init                    (GValue *value,
>                                              GType g_type);
> Initializes value with the default value of type.
> value : A zero-filled (uninitialized) GValue structure.
> g_type : Type the GValue should hold values of.
> Returns :  <no comment>
> 
> 
> The JNI code, however, uses the return statement:
> /*
>  * Class:     org.gnu.glib.Value
>  * Method:    g_value_init
>  * Signature: ([Lint ;I)I
>  */
> JNIEXPORT jint JNICALL Java_org_gnu_glib_Value_g_1value_1init (JNIEnv
> *env, jclass cls, 
>     jintArray value, jint type) 
> {
>     gint *value_g_g = (gint *) (*env)->GetIntArrayElements (env, value,
> NULL);
>     GValue *value_g = (GValue *)value_g_g;
>     GType type_g = (GType)&type;
>     {
>         return (jint)g_value_init (value_g, type_g);
>     }
> }
> 
> 
> Although this return value is ignored in the java code:
> /**
>  * Construct a new Value from a given org.gnu.glib.Value.
>  */
> public Value(Type type) {
> 	int [] vptr = new int[1];
> 	Value.g_value_init(vptr, type.getHandle());
> 	handle = vptr[0];
> }
> 
> Could someone who knows more about this please check it and either
> confirm that the Value code is correct or try to fix it.
> 
> Thanks
> -- 
> 
> +----------------------------------------------+
> | Mark Howard               cam.ac.uk   mh344@ |
> | http://www.tildemh.com    tildemh.com    mh@ |
> +----------------------------------------------+

Re: [java-gnome-hackers] Tree/List widgets

[Mark H. <mh...@ti...>]

On Fri, 2002-08-23 at 17:46, Mark Howard wrote:
> public Value(Type type) {
> 		int [] vptr =3D new int[1];
> 		Value.g_value_init(vptr, type.getHandle());
> 		handle =3D vptr[0];
> }

Has anyone successfully used the glib.Value object?=20

The gtk reference says:
GValue*     g_value_init                    (GValue *value,
                                             GType g_type);
Initializes value with the default value of type.
value : A zero-filled (uninitialized) GValue structure.
g_type : Type the GValue should hold values of.
Returns :  <no comment>


The JNI code, however, uses the return statement:
/*
 * Class:     org.gnu.glib.Value
 * Method:    g_value_init
 * Signature: ([Lint ;I)I
 */
JNIEXPORT jint JNICALL Java_org_gnu_glib_Value_g_1value_1init (JNIEnv
*env, jclass cls,=20
    jintArray value, jint type)=20
{
    gint *value_g_g =3D (gint *) (*env)->GetIntArrayElements (env, value,
NULL);
    GValue *value_g =3D (GValue *)value_g_g;
    GType type_g =3D (GType)&type;
    {
        return (jint)g_value_init (value_g, type_g);
    }
}


Although this return value is ignored in the java code:
/**
 * Construct a new Value from a given org.gnu.glib.Value.
 */
public Value(Type type) {
	int [] vptr =3D new int[1];
	Value.g_value_init(vptr, type.getHandle());
	handle =3D vptr[0];
}

Could someone who knows more about this please check it and either
confirm that the Value code is correct or try to fix it.

Thanks
--=20

+----------------------------------------------+
| Mark Howard               cam.ac.uk   mh344@ |
| http://www.tildemh.com    tildemh.com    mh@ |
+----------------------------------------------+

[java-gnome-hackers] looks like a vm bug

[Sergio R. <ser...@hi...>]

Hi folks!

I ran the WindowExample with kaffe vm and it executes correctly,
although it doesn't draw anything :(.

thanks.

[java-gnome-hackers] Tree/List widgets

[Mark H. <mh...@ti...>]

hi,
I've been working on these widgets. My initial aims were to implement
the minimum methods required to get something to work. I have
implemented these and written examples/gtk/tree/TreeExample.java to
demonstrate them. 
Unfortunately, I am having trouble to get this to work. 

In order to get this far, I had to make a few changes to some glib
classes:
Type: renamed the jni ...get_STRING method to getSTRING in both the java
and c files. (This will also have to be done with the other types)

Value: Added temporary methods for assigning values to the object.

The offending line in my test app appears to be:
Value val = new Value( Type.STRING() );
and in Value:
public Value(Type type) {
		int [] vptr = new int[1];
		Value.g_value_init(vptr, type.getHandle());
		handle = vptr[0];
}

I've attached the full java output.

I don't think the iter != null assertion is relevant to this particular
error (the iter isn't involved in the value). However, it too is a
strange error. There is no way of creating a new TreeIter.
list_store_append should create and return the iter.


Also, on a different note, How do I get access to the properties of the
objects (I don't really know much c). Take GtkCellRendererText for
example; This has no get/set methods, but has many read/write
properties. I assume something has to be added to the jni files. 
-- 

+----------------------------------------------+
| Mark Howard               cam.ac.uk   mh344@ |
| http://www.tildemh.com    tildemh.com    mh@ |
+----------------------------------------------+

[java-gnome-hackers] Internationalization code changes

[Philip A. C. <pc...@td...>]

I've finished up to org_gnu_gnome_FileEntry.c so far.  I'll continue to
work on the remainder.  It's not hard, just time consuming. :-)
--=20
Philip A. Chapman

[java-gnome-hackers] vm dump

[Sergio R. <ser...@hi...>]

Hi again friends.

I have tried to make the window example work with another method from
window class and it makes the virtual machine throw a horrible dump. The
example sucks but I want to be sure that it is not the java vm under ppc
arch the thing that has the bug.

vm dump:

 SIGSEGV   11*  segmentation violation
    si_signo [11]: SIGSEGV   11*  segmentation violation
    si_errno [0]: Success
    si_code [196609]: unknown siginfo
	stackpointer=0x7fffcbcc

Full thread dump Classic VM (Blackdown-1.3.1-02b-FCS, native threads):
    "Finalizer" (TID:0x30cc0528, sys_thread_t:0x10060780, state:CW,
native ID:0xc04) prio=8
	at java.lang.Object.wait(Native Method)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:108)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:123)
	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:162)
    "Reference Handler" (TID:0x30cc0300, sys_thread_t:0x1005a910,
state:CW, native ID:0x803) prio=10
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Object.java:420)
	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:110)
    "Signal Dispatcher" (TID:0x30cc0330, sys_thread_t:0x100588b0,
state:CW, native ID:0x402) prio=5
    "main" (TID:0x30cc01b0, sys_thread_t:0x1001b9a0, state:R, native
ID:0x400) prio=5
	at org.gnu.gdk.Window.gdk_window_get_toplevels(Native Method)
	at org.gnu.gdk.Window.getTopLevelWindows(Window.java:196)
	at WindowExample.main(WindowExample.java:10)
Monitor Cache Dump:
    java.lang.ref.ReferenceQueue$Lock@30CC0540/30CF6838: <unowned>
	Waiting to be notified:
	    "Finalizer" (0x10060780)
    java.lang.ref.Reference$Lock@30CC0310/30CF6340: <unowned>
	Waiting to be notified:
	    "Reference Handler" (0x1005a910)
Registered Monitor Dump:
    utf8 hash table: <unowned>
    JNI pinning lock: <unowned>
    JNI global reference lock: <unowned>
    BinClass lock: <unowned>
    Class linking lock: <unowned>
    System class loader lock: <unowned>
    Code rewrite lock: <unowned>
    Heap lock: <unowned>
    Monitor cache lock: owner "main" (0x1001b9a0) 1 entry
    Thread queue lock: owner "main" (0x1001b9a0) 1 entry
    Monitor registry: owner "main" (0x1001b9a0) 1 entry

[java-gnome-hackers] method missing

[Sergio R. <ser...@hi...>]

Hi guys!

Recently I have started to code a GdkWindow example.

The GdkWindow needs a top level window to build itself, so if I use a
null value, a GdkCritical is thrown and the example fails to start.
The problem is the Window class doesn't have the native
gdk_get_default_root_window wrapped.
I don't know how to build a Window, any suggestions? am I saying
something stupid?

I've also added a constructor to glib's List to build one List with a
handle.

Thankyou guys.