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

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

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

On Tue, 2002-09-03 at 19:11, Jeffrey Morgan wrote:
> Let me know if you want help with this.
I do.

I've been trying for quite a while now but have made little progress. I
changed the TreeIter append method to=20
JNIEXPORT jint JNICALL
Java_org_gnu_gtk_ListStore_gtk_1list_1store_1append (JNIEnv *env, jclass
cls, jint listStore)=20
  {
        GtkListStore *listStore_g =3D (GtkListStore *)listStore;
		GtkTreeIter *iter_g =3D (GtkTreeIter *) g_malloc(sizeof(GtkTreeIter));
        {
            gtk_list_store_append (listStore_g, iter_g);
        }
		return (jint)iter_g;
    }

This removed the iter errors.=20

But then there are a number of error relating the the glib.Value and
glib.Type classes. A number of them were resolved by bypassing those
classes and creating new set methods in ListStore (I had planned to do
something similar in the java code anyway):
JNIEXPORT void JNICALL
Java_org_gnu_gtk_ListStore_gtk_1list_1store_1set_1value_1string (JNIEnv
*env,=20
        jclass cls, jint listStore, jint iter, jint column, char*
strvalue)=20
    {
        GtkListStore *listStore_g =3D (GtkListStore *)listStore;
        GtkTreeIter *iter_g =3D (GtkTreeIter *)iter;
        gint32 column_g =3D (gint32) column;=09
	=09
		GValue *test;
        GValue *value_g =3D g_value_init(test, G_TYPE_STRING);
        {
            gtk_list_store_set_value (listStore_g, iter_g, column_g,
test);
		}
	}

This removed more of the warnings, but then I started to get strange
errors from the ListStore constructor (which still uses glib.Type).=20

I think the main error is probably something to do with constructing and
returning glib.Type objects.

Also, there could be problems with gtk_value_init in some places - this
takes and empty gvalue as an argument and should initialise it, but
there is also a gvalue returned - I'm not sure what this is.

I've not committed any of the above changes.=20
The src/examples/gtk/tree/TreeExample.java is still the current target
for testing.=20
--=20

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

[java-gnome-hackers] sorry about the late!

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

Hi again!
I've been preparing for the exams these days so I couldn't dedicate much
time to my hobbie. I've also been reading some papers about the jni
trying to understand the bindings better, and also playing a bit with
the mono platform and c#(pretty language).

I'm going to commit now a few changes so that Mark will be able to make
that lovely debian package with an alfa of the bindings in the near
future.

Another thing, the Window class in gdk should have a
gdk_get_default_root_window() so that you can build a new Window with
this returned window as its parent. Is this correct?
If it is correct, and now that I understand a bit the c code, can I take
a try and implement it myself? 

great!
Rubio Jr.

Re: [java-gnome-hackers] Event Handling proposal

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

On Tue, 2002-09-03 at 20:43, Philip A. Chapman wrote:
> I agree that GtkEvent should not allow arbitrary integers.  My
> suggestion would be to use org.gnu.glib.Enum.  That way it does not
> allow arbitrary values and it's use is consistant with the way things
> are done elsewhere in GTK.  Honestly, in my mind, I *thought* GtkEvent
> extended Enum; but I see now that it doesn't.

Event can't extend enum - it is created at the time the gtk signal is
made, including references to the source widget and possibly other data
(depending on the event).=20

The EventType class I used in the example contains both an integer value
and a String for each type. The integer is the ID and the string is used
in the GtkEvent.toString method (useful for debugging applications).
Hence, EventType classes would be best extending the EventType class I
defined in that example.=20

--=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...>]

Thanks. That does solve part of the problem. I will look into the rest
in the morning when I have more time.=20

The gtk.TreeModel class (jni and java) hasn't been created. Is there any
reason for this?

> > (java-gnome:2091): GLib-GObject-WARNING **:=20
> > gvalue.c:86:g_value_init():
> > cannot initialize GValue with type `(null)', the value has=20
> > already been
> > initialized as `(null)'
This error is still occurring though. I will see what I can find in the
morning.
--=20

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

Re: [java-gnome-hackers] Event Handling proposal

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

I agree that GtkEvent should not allow arbitrary integers.  My
suggestion would be to use org.gnu.glib.Enum.  That way it does not
allow arbitrary values and it's use is consistant with the way things
are done elsewhere in GTK.  Honestly, in my mind, I *thought* GtkEvent
extended Enum; but I see now that it doesn't.

On Tue, 2002-09-03 at 12:31, Mark Howard wrote:
> Hi,
> sorry for not suggesting this earlier - I was still learning how
> Java-gnome worked back then.=20
>=20
> I don't like the way event type checking is done:
> if (event.getId() =3D=3D KeyEvent.PRESSED){
> I think this would be better done something like:
> if (event.isOfType(KeyEvent.Type.PRESSED) ){
>=20
> This:
> - ensures a type is used, not any arbitrary integer
> - is immediately obvious to the developer
> - is readable
> - has better toString support (see below)
>=20
>=20
> I have created the following sources to show how I propose it should be
> done:
>=20
> GtkEvent.java:
> public class GtkEvent implements Serializable {
>   protected GtkEventType type;
>   protected Object source;
>=20
>   public GtkEvent(Object source, GtkEventType type) {
>     if (null =3D=3D source)
>        throw new IllegalArgumentException("null source");
>     this.source =3D source;
>     this.type =3D type;
>   }
>   public Object getSource() {
>     return source;
>   }
>   public int getType() {
>     return type;
>   }
>   public String toString() {
>    return getClass().getName() + "[source=3D" + source + ",id=3D" +
> type.getName() + "]";
>   }
> }
>=20
> GtkEventType.java:
> public class GtkEventType{
>   private int id;
>   private String name;
>   protected int getID(){
>     return id;
>   }
>   protected String getName(){
>     return name;
>   }
>   protected GtkEventType(int typeID, String typeName){
>     id =3D typeID;
>     name =3D typeName;
>   }
> }
>=20
> Sample Event (ButtonEvent.java):
> public class ButtonEvent extends GtkEvent {=09
>   public static class Type extends GtkEventType{
>     public static final ButtonEventType ACTIVATE =3D new ButtonEvent(1,
> "ACTIVATE");
>     public static final ButtonEventType CLICK =3D new ButtonEvent(2,
> "CLICK");
>     public static final ButtonEventType ENTER =3D new ButtonEvent(3,
> "ENTER");
>     public static final ButtonEventType LEAVE =3D new ButtonEvent(4,
> "Leave");
>     public static final ButtonEventType PRESS =3D new ButtonEvent(5,
> "PRESS");
>     public static final ButtonEventType RELEASE =3D new ButtonEvent(6,
> "RELEASE");
>    // the strings were defined separately using the old method.
>   }
>   public interface Listener{
>     public void buttonEvent(ButtonEvent event );
>   }
>   public ButtonEvent(Object source, ButtonEvent.Type type) {
>     super(source, type);
>   }
>   public boolean ofType(ButtonEvent.Type type){
>     return ( id =3D=3D type.getID());
>   }
> }
>=20
> I have not done extensive testing of this (as it would require changing
> all the events and methods which use them), but I see no reason why it
> shouldn't work - we are still dealing with exactly the same data.=20
>=20
> I think this should be done for the simple reason that=20
> event.isOfType( ButtonEvent.Type.CLICK )
> is far more obvious to the developer (and it is readable)
>=20
> The question of Type and Listener being done as inner classes is
> debatable. Perhaps listener should be separate.
>=20
> I am prepared to make the necessary changes to all the currently
> implemented events and classes which use these.=20
>=20
> Let me know your thoughts.
> --=20
>=20
> +----------------------------------------------+
> | Mark Howard               cam.ac.uk   mh344@ |
> | http://www.tildemh.com    tildemh.com    mh@ |
> +----------------------------------------------+
--=20
Philip A. Chapman

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

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

The primary problem with the first and third errors below are
that you must provide a valid TreeIter on a call to append.
You are just passing 0 as the TreeIter argument to gtk_list_store_append.
This is causing the first error.  Next, you are constructing a
TreeIter passing 0 to the constructor in the append method.  This
creates an invalid TreeIter which is later used, causing the third
error.

To resolve these problems I suggest making a change to the
generated code for ListStore (and all like classes) passing a
TreeIter* as an argument.  This will cause the native methods
to take an int array as the argument.  Using this method you will
be able to retrieve the updated TreeIter once the call is made.  You 
should be able to safely create a java TreeIter from this handle.  Also,
you will need to change the public interface for the append method requiring
a valid TreeIter.

Let me know if you want help with this.

-Jeff

> I'm now getting a different error:
> (java-gnome:2091): Gtk-CRITICAL **: file gtkliststore.c: line 1294
> (gtk_list_store_append): assertion `iter != 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=0x49df27d2
> Function name=g_type_check_value_holds
> Library=/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. 
> 
> -- 
> 
> +----------------------------------------------+
> | Mark Howard               cam.ac.uk   mh344@ |
> | http://www.tildemh.com    tildemh.com    mh@ |
> +----------------------------------------------+
> 

RE: [java-gnome-hackers] MouseEvent problems

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

I am currently looking at the problem you are having with
ListStore, etc.  After this I intend to refocus on the 
event propagation.  There are a couple of serious bugs
that exist that I hope to resolve.  The problem you are
experiencing with the Mouse events are an example of one of
the problems.

-Jeff

> Jeff-
> Are you currently working on the Widget event handling, or do you know
> of existing problems? 
> 
> I've been having problems trying to use the MouseListener 
> (for the leave
> and enter events). 
> When running, the program does not produce any error output - 
> sometimes
> it just freezes. 
> jdb picks up the following:
> Exception occurred: java.lang.NullPointerException (uncaught)
> thread="main", org.gnu.gtk.Widget.handleMouseEnter(), line=806, bci=1
> 
> This is also happening for key presses, which I hadn't set a listener
> for.
> Exception occurred: java.lang.NullPointerException (uncaught)
> thread="main", org.gnu.gtk.Widget.handleKeyPressed(), line=721, bci=1
> 
> -- 
> 
> +----------------------------------------------+
> | Mark Howard               cam.ac.uk   mh344@ |
> | http://www.tildemh.com    tildemh.com    mh@ |
> +----------------------------------------------+
> 

RE: [java-gnome-hackers] Event Handling proposal

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

I like this idea. 

-Jeff

> Hi,
> sorry for not suggesting this earlier - I was still learning how
> Java-gnome worked back then. 
> 
> I don't like the way event type checking is done:
> if (event.getId() == KeyEvent.PRESSED){
> I think this would be better done something like:
> if (event.isOfType(KeyEvent.Type.PRESSED) ){
> 
> This:
> - ensures a type is used, not any arbitrary integer
> - is immediately obvious to the developer
> - is readable
> - has better toString support (see below)
> 
> 
> I have created the following sources to show how I propose it 
> should be
> done:
> 
> GtkEvent.java:
> public class GtkEvent implements Serializable {
>   protected GtkEventType type;
>   protected Object source;
> 
>   public GtkEvent(Object source, GtkEventType type) {
>     if (null == source)
>        throw new IllegalArgumentException("null source");
>     this.source = source;
>     this.type = type;
>   }
>   public Object getSource() {
>     return source;
>   }
>   public int getType() {
>     return type;
>   }
>   public String toString() {
>    return getClass().getName() + "[source=" + source + ",id=" +
> type.getName() + "]";
>   }
> }
> 
> GtkEventType.java:
> public class GtkEventType{
>   private int id;
>   private String name;
>   protected int getID(){
>     return id;
>   }
>   protected String getName(){
>     return name;
>   }
>   protected GtkEventType(int typeID, String typeName){
>     id = typeID;
>     name = typeName;
>   }
> }
> 
> Sample Event (ButtonEvent.java):
> public class ButtonEvent extends GtkEvent {	
>   public static class Type extends GtkEventType{
>     public static final ButtonEventType ACTIVATE = new ButtonEvent(1,
> "ACTIVATE");
>     public static final ButtonEventType CLICK = new ButtonEvent(2,
> "CLICK");
>     public static final ButtonEventType ENTER = new ButtonEvent(3,
> "ENTER");
>     public static final ButtonEventType LEAVE = new ButtonEvent(4,
> "Leave");
>     public static final ButtonEventType PRESS = new ButtonEvent(5,
> "PRESS");
>     public static final ButtonEventType RELEASE = new ButtonEvent(6,
> "RELEASE");
>    // the strings were defined separately using the old method.
>   }
>   public interface Listener{
>     public void buttonEvent(ButtonEvent event );
>   }
>   public ButtonEvent(Object source, ButtonEvent.Type type) {
>     super(source, type);
>   }
>   public boolean ofType(ButtonEvent.Type type){
>     return ( id == type.getID());
>   }
> }
> 
> I have not done extensive testing of this (as it would 
> require changing
> all the events and methods which use them), but I see no reason why it
> shouldn't work - we are still dealing with exactly the same data. 
> 
> I think this should be done for the simple reason that 
> event.isOfType( ButtonEvent.Type.CLICK )
> is far more obvious to the developer (and it is readable)
> 
> The question of Type and Listener being done as inner classes is
> debatable. Perhaps listener should be separate.
> 
> I am prepared to make the necessary changes to all the currently
> implemented events and classes which use these. 
> 
> Let me know your thoughts.
> -- 
> 
> +----------------------------------------------+
> | Mark Howard               cam.ac.uk   mh344@ |
> | http://www.tildemh.com    tildemh.com    mh@ |
> +----------------------------------------------+
> 

[java-gnome-hackers] Event Handling proposal

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

Hi,
sorry for not suggesting this earlier - I was still learning how
Java-gnome worked back then.=20

I don't like the way event type checking is done:
if (event.getId() =3D=3D KeyEvent.PRESSED){
I think this would be better done something like:
if (event.isOfType(KeyEvent.Type.PRESSED) ){

This:
- ensures a type is used, not any arbitrary integer
- is immediately obvious to the developer
- is readable
- has better toString support (see below)


I have created the following sources to show how I propose it should be
done:

GtkEvent.java:
public class GtkEvent implements Serializable {
  protected GtkEventType type;
  protected Object source;

  public GtkEvent(Object source, GtkEventType type) {
    if (null =3D=3D source)
       throw new IllegalArgumentException("null source");
    this.source =3D source;
    this.type =3D type;
  }
  public Object getSource() {
    return source;
  }
  public int getType() {
    return type;
  }
  public String toString() {
   return getClass().getName() + "[source=3D" + source + ",id=3D" +
type.getName() + "]";
  }
}

GtkEventType.java:
public class GtkEventType{
  private int id;
  private String name;
  protected int getID(){
    return id;
  }
  protected String getName(){
    return name;
  }
  protected GtkEventType(int typeID, String typeName){
    id =3D typeID;
    name =3D typeName;
  }
}

Sample Event (ButtonEvent.java):
public class ButtonEvent extends GtkEvent {=09
  public static class Type extends GtkEventType{
    public static final ButtonEventType ACTIVATE =3D new ButtonEvent(1,
"ACTIVATE");
    public static final ButtonEventType CLICK =3D new ButtonEvent(2,
"CLICK");
    public static final ButtonEventType ENTER =3D new ButtonEvent(3,
"ENTER");
    public static final ButtonEventType LEAVE =3D new ButtonEvent(4,
"Leave");
    public static final ButtonEventType PRESS =3D new ButtonEvent(5,
"PRESS");
    public static final ButtonEventType RELEASE =3D new ButtonEvent(6,
"RELEASE");
   // the strings were defined separately using the old method.
  }
  public interface Listener{
    public void buttonEvent(ButtonEvent event );
  }
  public ButtonEvent(Object source, ButtonEvent.Type type) {
    super(source, type);
  }
  public boolean ofType(ButtonEvent.Type type){
    return ( id =3D=3D type.getID());
  }
}

I have not done extensive testing of this (as it would require changing
all the events and methods which use them), but I see no reason why it
shouldn't work - we are still dealing with exactly the same data.=20

I think this should be done for the simple reason that=20
event.isOfType( ButtonEvent.Type.CLICK )
is far more obvious to the developer (and it is readable)

The question of Type and Listener being done as inner classes is
debatable. Perhaps listener should be separate.

I am prepared to make the necessary changes to all the currently
implemented events and classes which use these.=20

Let me know your thoughts.
--=20

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

[java-gnome-hackers] MouseEvent problems

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

Jeff-
Are you currently working on the Widget event handling, or do you know
of existing problems?=20

I've been having problems trying to use the MouseListener (for the leave
and enter events).=20
When running, the program does not produce any error output - sometimes
it just freezes.=20
jdb picks up the following:
Exception occurred: java.lang.NullPointerException (uncaught)
thread=3D"main", org.gnu.gtk.Widget.handleMouseEnter(), line=3D806, bci=3D1

This is also happening for key presses, which I hadn't set a listener
for.
Exception occurred: java.lang.NullPointerException (uncaught)
thread=3D"main", org.gnu.gtk.Widget.handleKeyPressed(), line=3D721, bci=3D1

--=20

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

RE: [java-gnome-hackers] Widget ref and unref

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

On Tue, 2002-09-03 at 14:25, Jeffrey Morgan wrote:
> Can we take a step back and discuss the root problem
> we are trying to solve with the ref and unref?  There=20
> might be other solutions to the problem.

AFAIK:=20
Gtk frees objects when it thinks they are done with. One consequence of
this is that it is currently impossible in Java-gnome to remove a widget
from a table and the put the widget back into the table at a later time.
To make gtk know that the widgets are not finished with, the=20
gtk_widget_ref or g_object_ref methods should be called
To allow the object to be freed, a call has to be made to
gtk_widget_unref or g_object_unref

Java developers won't expect a widget to disappear when the Java object
for it still exists. so, IMHO, we need to 'ref each widget as it is
created and unref it when the java object is destroyed (gtk will not
free the object until there are no internal gtk references to it (e.g.
as part of another widget) and the unref has been made).

My original way of doing this was to add the ref to the
initialiseEventHandlers method, as this is called whenever an object is
instantiated; and add the unref to a finally clause. This has the
problem that finally is not guaranteed to be called.=20

I guess (but don't know) that gtk will free the object regardless when
it is asked to finish, so the only problem would be while the program is
running. If not, the OS should clear up on exit, but that's not a good
way to do it.
--=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 Tue, 2002-09-03 at 14:23, Jeffrey Morgan wrote:
> Are you still having this problem? =20
yes.

>If so I hope
> to look into it now.

Thanks.

>
> -Jeff
>=20
> > -----Original Message-----
> > From: Mark Howard [mailto:mh...@ti...]
> > Sent: Friday, August 30, 2002 9:40 AM
> > To: jav...@li...
> > Subject: RE: [java-gnome-hackers] Tree/List widgets
> >=20
> >=20
> > 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?
> >=20
> > My original test is in src/examples/gtk/tree/TreeExample.java
> > (it's actually a list example, but that's not important)
> >=20
> > 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
> >=20
> > (java-gnome:2091): GLib-GObject-WARNING **:=20
> > gvalue.c:86:g_value_init():
> > cannot initialize GValue with type `(null)', the value has=20
> > already been
> > initialized as `(null)'
> > An unexpected exception has been detected in native code=20
> > 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
> >=20
> > 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)
> >=20
> > It's the same line, but looks like a problem with glib.Type=20
> > this time.=20
> >=20
> > --=20
> >=20
> > +----------------------------------------------+
> > | Mark Howard               cam.ac.uk   mh344@ |
> > | http://www.tildemh.com    tildemh.com    mh@ |
> > +----------------------------------------------+
> >=20
--=20

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

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

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

You can overload the constructor and make it private.

-Jeff

> I agree that it is a bad thing for About to not inherit from Dialog. 
> Again, my concern is that an unecessary (from About's point 
> of view, not
> unecessary for Dialog).  I'll look into this further to see if there's
> another solution.
> 
> I never ment the change to be perminant.  I did it while trying to get
> things to work, and wrote to you about it so you'd know what I was
> thinking.  I'll change the inheritance back if you haven't already.
> 
> On Tue, 2002-09-03 at 08:44, Jeffrey Morgan wrote:
> > It is very important that we maintain the same
> > object hierarchy that exists in the native libs.
> > If we don't, calls on parent methods will fail.
> > About must inherit from Dialog.  
> > 
> > -Jeff
> > 
> > > Since About extended Dialog, Dialog's empty parameter 
> constructor was
> > > run.  This constructor makes a native call which allocates 
> > > memory for a
> > > gtk dialog which is never used.  Maybe we don't care since it 
> > > should be
> > > cleaned up in the finalize event?  I changed About so 
> that it extends
> > > Window, but am not sure that this the *correct* answer.
> -- 
> Philip A. Chapman
> 

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

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

I agree that it is a bad thing for About to not inherit from Dialog.=20
Again, my concern is that an unecessary (from About's point of view, not
unecessary for Dialog).  I'll look into this further to see if there's
another solution.

I never ment the change to be perminant.  I did it while trying to get
things to work, and wrote to you about it so you'd know what I was
thinking.  I'll change the inheritance back if you haven't already.

On Tue, 2002-09-03 at 08:44, Jeffrey Morgan wrote:
> It is very important that we maintain the same
> object hierarchy that exists in the native libs.
> If we don't, calls on parent methods will fail.
> About must inherit from Dialog. =20
>=20
> -Jeff
>=20
> > Since About extended Dialog, Dialog's empty parameter constructor was
> > run.  This constructor makes a native call which allocates=20
> > memory for a
> > gtk dialog which is never used.  Maybe we don't care since it=20
> > should be
> > cleaned up in the finalize event?  I changed About so that it extends
> > Window, but am not sure that this the *correct* answer.
--=20
Philip A. Chapman

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

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

Since all Gnome applications will need to call the GnomeProgram
init methods prior to calling any other API you should only have
to put the loading of the library in GnomeProgram.

-Jeff

> I'll also go though the classes and make sure that libGNOMEJava.so is
> loaded.

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

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

Thanks.  At least I'm not going insane.  I'll do exactly what you
suggest and take a long hard look at src/code/jni/java and
src/code/jni/glue.

I'll also go though the classes and make sure that libGNOMEJava.so is
loaded.

On Tue, 2002-09-03 at 08:42, Jeffrey Morgan wrote:
> The problem you are having is that you are initializing
> TestGNOME with a call to Gtk.init().  This will not work
> for GNOME applications.  You will need to use one of the
> GnomeProgram init methods.  Also, we need to make sure=20
> that the libGNOMEJava.so shared object is loaded.  This
> should also happen in the GnomeProgram object.  You might
> take a look at some old code that is in src/code/jni/java
> and src/code/jni/glue for the GnomeProgram object.  A
> cleaner implementation of this might work.
>=20
--=20
Philip A. Chapman

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

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

It is very important that we maintain the same
object hierarchy that exists in the native libs.
If we don't, calls on parent methods will fail.
About must inherit from Dialog.  

-Jeff

> Since About extended Dialog, Dialog's empty parameter constructor was
> run.  This constructor makes a native call which allocates 
> memory for a
> gtk dialog which is never used.  Maybe we don't care since it 
> should be
> cleaned up in the finalize event?  I changed About so that it extends
> Window, but am not sure that this the *correct* answer.

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

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

The problem you are having is that you are initializing
TestGNOME with a call to Gtk.init().  This will not work
for GNOME applications.  You will need to use one of the
GnomeProgram init methods.  Also, we need to make sure 
that the libGNOMEJava.so shared object is loaded.  This
should also happen in the GnomeProgram object.  You might
take a look at some old code that is in src/code/jni/java
and src/code/jni/glue for the GnomeProgram object.  A
cleaner implementation of this might work.

-Jeff

> I've done a CVS commit of what I have so far  Here are the problems I
> found and tried to fix:
> 
> About's constructor couldn't handle pixmap being null.  The strange
> thing is that I wasn't getting a null pointer exception, but it was
> hanging when running.  When debugging, I'd get the exception???
> 
> Since About extended Dialog, Dialog's empty parameter constructor was
> run.  This constructor makes a native call which allocates 
> memory for a
> gtk dialog which is never used.  Maybe we don't care since it 
> should be
> cleaned up in the finalize event?  I changed About so that it extends
> Window, but am not sure that this the *correct* answer.
> 
> The results I see using jdb have been inconsistent.  Most of 
> the time, I
> end with an unsatisfied link error; but once I managed to get into a
> loop calling the button event handler???  I *think* the 
> unsatisfied link
> error may be the clue I need.  I've got my LD_LIBRARY_PATH variable
> pointing to java-gnome/lib.  The fact that I can create and view the
> main window and the Dialog indicates to me that the libraries can be
> found.
> 
> I've tried attaching to the VM with gdb as suggested in
> http://www-106.ibm.com/developerworks/java/library/j-jnidebug/
?dwzone=java but have had little success.

Long story long, this has been very frustrating.  I feel that this is a
function of me just not having any experience debugging JNI calls; but I
felt I'd do better than this!

What do I need to set up in eclipse to have this all work?  I've loaded
the java-gnome/.project and set the path to the java JDK (BlackDown
1.3.1).  I'll install the C/C++ development stuff as you suggest.

On Sat, 2002-08-31 at 07:22, Jeffrey Morgan wrote:
> One other thing I forgot to mention.  You will want to
> get the C/C++ development plugin for eclipse.  You can
> find it here:
> 
>
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/cdt-home/main.html?c
vsroot=Tools_Project
> 
> 
> 
> 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
> 
> 
> 
> 
> -------------------------------------------------------
> 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
-- 
Philip A. Chapman

RE: [java-gnome-hackers] Widget ref and unref

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

Can we take a step back and discuss the root problem
we are trying to solve with the ref and unref?  There 
might be other solutions to the problem.

-Jeff

> The problem I see with this is specifying the location of the
> targetQueue. I can't think of any robust way to do this without
> modifying the constructor of every widget.
> 
> Does anyone on the list have any ideas?

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

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

Are you still having this problem?  If so I hope
to look into it now.

-Jeff

> -----Original Message-----
> From: Mark Howard [mailto:mh...@ti...]
> Sent: Friday, August 30, 2002 9:40 AM
> To: jav...@li...
> Subject: RE: [java-gnome-hackers] Tree/List widgets
> 
> 
> 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 != 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=0x49df27d2
> Function name=g_type_check_value_holds
> Library=/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. 
> 
> -- 
> 
> +----------------------------------------------+
> | Mark Howard               cam.ac.uk   mh344@ |
> | http://www.tildemh.com    tildemh.com    mh@ |
> +----------------------------------------------+
> 

Re: [java-gnome-hackers] Widget ref and unref

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

Perhaps we create a static method to GObject which will return the
queue.  Since all java-gnome objects will use the same queue, a static
call should be fine.  Of course, a reference to the queue itself would
have to be a static member of the class.

We then create a protected method setHandle(int handle) to GObject and
make the member handle private.  We'd have to change all constructors to
call setHandle rather than to use handle directly.  We could then add
the code to queue an object into GObject.setHandle() since you know that
you've allocated native memory at that point.

This doesn't change the fact that we have to change every constructor,
but at least it's only a one line change.

On Sat, 2002-08-31 at 07:40, Mark Howard wrote:
> The problem I see with this is specifying the location of the
> targetQueue. I can't think of any robust way to do this without
> modifying the constructor of every widget.
>=20
> Does anyone on the list have any ideas?
> --=20
>=20
> +----------------------------------------------+
> | Mark Howard               cam.ac.uk   mh344@ |
> | http://www.tildemh.com    tildemh.com    mh@ |
> +----------------------------------------------+
--=20
Philip A. Chapman

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

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

I've done a CVS commit of what I have so far  Here are the problems I
found and tried to fix:

About's constructor couldn't handle pixmap being null.  The strange
thing is that I wasn't getting a null pointer exception, but it was
hanging when running.  When debugging, I'd get the exception???

Since About extended Dialog, Dialog's empty parameter constructor was
run.  This constructor makes a native call which allocates memory for a
gtk dialog which is never used.  Maybe we don't care since it should be
cleaned up in the finalize event?  I changed About so that it extends
Window, but am not sure that this the *correct* answer.

The results I see using jdb have been inconsistent.  Most of the time, I
end with an unsatisfied link error; but once I managed to get into a
loop calling the button event handler???  I *think* the unsatisfied link
error may be the clue I need.  I've got my LD_LIBRARY_PATH variable
pointing to java-gnome/lib.  The fact that I can create and view the
main window and the Dialog indicates to me that the libraries can be
found.

I've tried attaching to the VM with gdb as suggested in
http://www-106.ibm.com/developerworks/java/library/j-jnidebug/?dwzone=3Djav=
a but have had little success.

Long story long, this has been very frustrating.  I feel that this is a
function of me just not having any experience debugging JNI calls; but I
felt I'd do better than this!

What do I need to set up in eclipse to have this all work?  I've loaded
the java-gnome/.project and set the path to the java JDK (BlackDown
1.3.1).  I'll install the C/C++ development stuff as you suggest.

On Sat, 2002-08-31 at 07:22, Jeffrey Morgan wrote:
> One other thing I forgot to mention.  You will want to
> get the C/C++ development plugin for eclipse.  You can
> find it here:
>=20
> http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/cdt-home/main.htm=
l?cvsroot=3DTools_Project
>=20
>=20
>=20
> On Fri, 2002-08-30 at 19:56, Philip A. Chapman wrote:
> > Jeff,
> >=20
> > 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.=20
> > Therefore, I need to do some debugging in the native code to determine
> > what's happening.
> >=20
> > 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.
> >=20
> > It appears that the other classes the TestGNOME application have simila=
r
> > problem too.
> >=20
> > I wanted to install eclipse anyway, but haven't taken the time until
> > now.  :-)
> > --=20
> > Philip A. Chapman
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> 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=3Dsourceforge1&refcode1=3Dvs3390
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
--=20
Philip A. Chapman

Re: [java-gnome-hackers] Widget ref and unref

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

On Thu, 2002-08-29 at 11:45, VEROK Istvan wrote:=20
>=20
> Hi!=20
>=20
> Sorry to butt in on a topic I know little about (Java-GNOME itself),
but I=20
> was browsing the java-gnome-hackers mailing list archives and your
mail=20
> about widget (un)referencing caught my eye.  You currently want to use
the=20
> finalize() method for cleanup once the Java GC loses sight of the
object=20
> reference, but it's not safe.  There's absolutely no guarantee that
the=20
> finalize() method ever gets called.=20
>=20
> A better solution is the java.lang.ref package, present since Java
1.2.=20
> You could use a soft reference to track whether an object instance is=20
> unreachable, or a phantom reference if you're totally paranoid about
the=20
> others.  It's a cleaner and more timely way.=20
>=20
> Regards,=20
> VEROK Istvan=20



On Sat, 2002-08-31 at 11:40, VEROK Istvan wrote:=20
> > I do not see how a java.lang.ref would help in this situation -
please=20
> > explain more.=20
>=20
> Okay, here's what I'm thinking: as now, call gtk_widget_ref (or
whatever=20
> the native method is named) in the widget's constructor, and also
create=20
> java.lang.ref.WeakReference that points to this widget, to be enqueued
> into some commonly known java.lang.ref.ReferenceQueue.=20
> (This basically means that you say=20
> new WeakReference(refedWidget, targetQueue); )=20
>=20
> Being a WeakReference means that the object pointed to (the widget, in
> this case) is no longer strongly reachable (along the usual Java=20
> references), nor is it softly reachable (along a chain of usual and=20
> java.lang.ref.SoftReference instances), but it is reachable weakly.=20
> When this happens, the GC enqueues the reference (simply adds it to
the=20
> targetQueue specified in the above constructor call).=20
>=20
> So the point is that you could have a daemon thread (or do this=20
> periodically among normal activities) to see if the ReferenceQueue now
> contains any enqueued references.  (A targetQueue.poll() call will
tell=20
> you without blocking, or a targetQueue.remove() will block until it
can=20
> return one.)  If yes:=20
> ((GtkWidget)targetQueue.remove().get()).gtk_widget_unref();=20
>=20
> So this is a point in time when there are definitely no more usual=20
> references to the widget (the weak reference being enqueued means just
> that), and we can call its native method to unreference its native=20
> resources.=20
>=20
> One more thing: why a weak reference and not a phantom reference,
since=20
> that is even more stringent (no more weak references)?  Because with=20
> phantom references you cannot get() the referred reference back -- it=20
> always returns null, to ensure you cannot "revive" your object in this
> way.=20
>=20
> If you abstract this unref-ing activity out to a Runnable, you might
want=20
> to register it with=20
> java.lang.Runtime.addShutdownHook(new Thread(theRunnable));=20
> too, since that runs it also when the JVM is about to be shut down.=20
>=20
> Just my $0.02 -- wish I could help more with Java-GNOME, but I don't
know=20
> GTK.  Any tentative release dates for 0.8.0?=20
>=20
> Regards,=20
> Istvan=20


The problem I see with this is specifying the location of the
targetQueue. I can't think of any robust way to do this without
modifying the constructor of every widget.

Does anyone on the list have any ideas?
--=20

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

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

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

One other thing I forgot to mention.  You will want to
get the C/C++ development plugin for eclipse.  You can
find it here:

http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/cdt-home/main.html?cvsroot=Tools_Project



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

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

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

I will try to take a look over the weekend.

On Fri, 2002-08-30 at 09:39, Mark Howard wrote:
> 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 != 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=0x49df27d2
> Function name=g_type_check_value_holds
> Library=/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. 
> 
> -- 
> 
> +----------------------------------------------+
> | Mark Howard               cam.ac.uk   mh344@ |
> | http://www.tildemh.com    tildemh.com    mh@ |
> +----------------------------------------------+