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

[java-gnome-hackers] [VACATION] 2 months

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

Hi,
I'm going back to uni at the weekend, so will be able to do little work
until the start of December. If any bugs come up in my code, please let
me know - I might be be able to find little bits of time (they say the
second year is the easiest).=20
I will try to keep maintaining my Debian packages. I get a 10MB net
connection next week, so will post the apt-get lines for java-gnome
snapshot packages (They are complete and working, just need uploading).
I will probably not upload to Debian main  until ant is moved from
contrib to main.
Please don't give up on java-gnome - A lot of work has been done so far
and a 0.8 release is sure to generate more interest (and more bug
patches)

Here's my list of Gtk todo items which I now won't be able to complete:
- TreeSortable functions
- TreeSelelection
- TreeSelection select function=20
- TreeView Column drag function
- TreeView map extended rows function
- some CellRenderer... events
- TextBuffer signals
- TextView signals
- TextTag
- TextTagTableSignals
- Clipboard

AFAIK, there are also the following gtk items to do:
- Image releated widgets
- socket/plug.

Good luck. I look forward to reading about the 0.8.0 release in the
coming weeks.
--=20

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

[java-gnome-hackers] Multiple threads

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

Hi,
  I'm working on an application which has a gui thread and a worker
thread which performs a continuous action. I'm wanting to have a
progress bar (handled by the gui thread) updated by the worker thread.
How is this done?

How is it usually done in Gtk? (the only ideas I have at the moment
involve creating custom events and calling those)
--=20

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

[java-gnome-hackers] JNI code review

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

Hi,
I've been working on some complicated JNI code. All my testing shows
that it works, but I would prefer it if someone more experienced with
jni would take a look also.=20

TreeSelection=20
  - ForEach methods (this involves calling a java method many times for
each selected item)
glib.Value
  - Added support for storing Java Objects (They can then be stored in
TreeStore and ListStore objects).


BTW: What are the plans for 0.8.0 release?  I think I can get the Tree
and Text widgets complete this week which should (I think) finish off
the gtk widgets; what else needs doing?
--=20

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

[java-gnome-hackers] bugs fixed

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

Hi,
I've commited some code to temporarily hide the bugs with signal
handling. Remaining issues:

* ToggleButton signals do not work (I've disabled them in
ToggleButton.java).=20
jobject_to_gtk in org_gnu_glib_GObject.c seems to be returning a
GtkButton rather than GtkToggleButton in this case - I can't see why.

* Signal handling involving Boxed type parameters do not work - they
return null. I have ignored the boxed parameters in the handleZZZ
methods of Widget (they were previously passed to constructor of the
event and not used anywhere).=20
This is most probably caused by an error in jg_signal_cb of
org_gnu_glib_GObject.c. I have not been able to determine why.

If anyone has any ideas how to fix these (particularly the first),
please try.=20
--=20

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

[java-gnome-hackers] signals

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

Jeff-
Are you getting anywhere with these signal problems? Could you possibly
give an idea of what you think the problems are (just hard to find
bugs/functions which you need to change to work differently/...)

Also, if you want help with this, please let us know exactly which
functions you think could be causing the main problems.

I've been looking at the gobject code this morning and have been finding
that the wrong object type is sometimes passed to native methods, e.g.
for the toggled event of ToggleButton's, adding an extra line=20

printf("TESTING: G_OBJECT_TYPE_NAME: %s, class name
%s",G_OBJECT_TYPE_NAME(go), G_OBJECT_CLASS_NAME(go));=20
printf("***ERROR***:  Java-GNOME - unknown signal name %s, function
%s.\n", signame, sigfunc);

to the create_callback function (line 564)
has the result of GtkButton and so the signal name is unknown (as it is
a signal of GtkToggleButton).=20

Please let us know what we can work on to help get this fixed.=20
--=20

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

Re: [java-gnome-hackers] Constructors for Canvas Items

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

Mark,

Thanks for the reply.  I appreciate you taking the time to look at it.=20
I'll modify TestGNOME so that I can test this new code out.  I just
wanted to get some feedback on the proof of concept before I went too
much further with it.

Thanks Again,

On Sat, 2002-09-21 at 08:47, Mark Howard wrote:
> Sorry, don't have the gnome docs at the moment. Where this happens in
> Gtk, they usually create a number of methods specifically for bindings,
> including new() and setValue(String, whatever)
>=20
> The way you do it seems good though. Test apps would be a good way to
> verify that the c code works - it looks fine.=20
> --=20
>=20
> +----------------------------------------------+
> | Mark Howard               cam.ac.uk   mh344@ |
> | http://www.tildemh.com    tildemh.com    mh@ |
> +----------------------------------------------+
--=20
Philip A. Chapman

Re: [java-gnome-hackers] Constructors for Canvas Items

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

On Sat, 2002-09-21 at 04:38, Philip A. Chapman wrote:
> Everyone,
>=20
> Gnome canvas items are a little unique.  There is a single constructor
> function that takes a parameter list with a variable number of
> parameters:
[snip]
> I think that this approach will work, but I am not sure that it is the
> best way or that I have done it 100% correctly.  I would appreciate any
> input you may have on the code in the java classes or the C source.

Sorry, don't have the gnome docs at the moment. Where this happens in
Gtk, they usually create a number of methods specifically for bindings,
including new() and setValue(String, whatever)

The way you do it seems good though. Test apps would be a good way to
verify that the c code works - it looks fine.=20
--=20

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

[java-gnome-hackers] Constructors for Canvas Items

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

Everyone,

Gnome canvas items are a little unique.  There is a single constructor
function that takes a parameter list with a variable number of
parameters:

GnomeCanvasItem * gnome_canvas_item_new(GnomeCanvasGroup * parent,
     GtkType type, const gchar * first_arg_name, ...);

How many and what types of parameters are sent after first_arg_name
depend on what subtype of CanvasItem you are creating.  To begin with, I
started with CanvasRE and its subclasses CanvasEllipse and CanvasRect.=20
I have implemented 4 custom C functions in org_gnu_gnome_CanvasRE.c
which wrap the C constructor function mentioned above.  Each of the
subclasses have 4 constructors.

I think that this approach will work, but I am not sure that it is the
best way or that I have done it 100% correctly.  I would appreciate any
input you may have on the code in the java classes or the C source.
--=20
Philip A. Chapman

[java-gnome-hackers] TextTag Properties

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

Hi,
Jeff, when you get time to look at making code for the treeModel, could
you also please look at writing generator code for get/set methods for
the properties of TextTag, using the g_object_get/set methods
--=20

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

Re: [java-gnome-hackers] Native handle Constructors for 2 org.gnu.gtk objects

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

On Thu, 2002-09-12 at 05:15, Philip A. Chapman wrote:
> Jeff or Mark,
>=20
> When you have the opportunity, I need constructors with handle as a
> parameter for StatusBar and MenuBar.
done
--=20

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

[java-gnome-hackers] Native handle Constructors for 2 org.gnu.gtk objects

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

Jeff or Mark,

When you have the opportunity, I need constructors with handle as a
parameter for StatusBar and MenuBar.
--=20
Philip A. Chapman

[java-gnome-hackers] function help wanted | MultiLine Text Editor

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

Hi,
Once the TreeModel object is complete, the remaining work for trees and
lists will be related to the functions where functions are taken as
arguments:
- TreeSelection - function for iterating over all selected iters;
selectability test
- TreeSortable - comparator functions.
- TreeView -columnDrag, map-expanded-rows.
I don't really know enough jni/c to tackle these, so if someone would
volunteer to help, that would be great. The tree selection functions are
quite important as they are the only way of finding which cells are
selected. The others are not so urgent.


If there's no objections, I'll start work on the final chunk of gtk
objects, the text editor.=20
--=20

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

RE: [java-gnome-hackers] Tree Success!!

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

On Wed, 2002-09-11 at 14:02, Mark Howard wrote:
[snip]
> If possible, could you also look into how to access the 'properties' of
> the CellRenderers (CellRendererText in particular has many of these). I
> had manually written code in CellRendererText jni code to do this, but
> it doesn't work for all the properties (It does for some though). I'm
> not really sure how this should be done.=20

I think I've sorted this now, so you don't need to look into it.
--=20

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

RE: [java-gnome-hackers] Tree Success!!

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

On Wed, 2002-09-11 at 13:32, Jeffrey Morgan wrote:
>=20
> > - TreeModel:
> > Jeff- you said you would be able to run the code generator to make the
> > basis for this. Could you do that sometime and send me the results.
>=20
> I will do this today if it is still needed.  Let me know
> where you are at Mark.
yes, TreeModel is needed, thanks.

ListStore doesn't need doing though. That was mostly fine, other changes
have been done manually.

If possible, could you also look into how to access the 'properties' of
the CellRenderers (CellRendererText in particular has many of these). I
had manually written code in CellRendererText jni code to do this, but
it doesn't work for all the properties (It does for some though). I'm
not really sure how this should be done.=20

--=20

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

RE: [java-gnome-hackers] Tree Success!!

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

Sorry for being mostly out of touch.  I have been hammered
at work lately.  I have made some progress with the event
handling but it is still not working as I would like.  My
target is to have this cleaned up this week.

Mark, do you still need me to modify the defs file and
run the generator for the ListStore rework?  If so I will
do that this week as well.

-Jeff

> Hello!
>   I've finally managed to fix the tree view / glib.Value problems. The
> changes will be commit'ed in a moment and then I'll finally start work
> on the rest of the tree functionality. 
> 
> Jeff:
>   Are you getting anywhere with the focus event problems? It would be
> really useful if you could either fix them or temporarily disable that
> part of the code, so that we can run test apps without crashes on
> startup.

RE: [java-gnome-hackers] Tree Success!!

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

> - TreeModel:
> Jeff- you said you would be able to run the code generator to make the
> basis for this. Could you do that sometime and send me the results.

I will do this today if it is still needed.  Let me know
where you are at Mark.

-Jeff

Re: [java-gnome-hackers] Tree Success!!

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

- TreeModel:
Jeff- you said you would be able to run the code generator to make the
basis for this. Could you do that sometime and send me the results.

I've now completed much of the tree, list and table functionality. Test
applications are in=20
examples/gtk/tree/TreeExample.java
and
examples/gtk/dataTable/TableExample.java=20

I've also started work on SimpleList.java, a wrapper for those objects

Still to be done:
- All event handling (many of the parameters are very poorly
documented). If anyone who knows more about the tree events wants to
help, please do.=20
- More work improving the documentation
- drag and drop (I'm not interested this. I have done the gtk internal
drag and drop wrappers (such as reordering table columns), but the
custom ones seem less appealing)
- CellRendererText 'properties'. I could do with some help on this - I'm
not entirely sure how/where they are stored. Related code is in
org_gnu_gtk_CellRendererText.c
- TreeSortable
- possibly more wrapper classes like SimpleList.
--=20

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

[java-gnome-hackers] Tree Success!!

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

Hello!
  I've finally managed to fix the tree view / glib.Value problems. The
changes will be commit'ed in a moment and then I'll finally start work
on the rest of the tree functionality.=20

Jeff:
  Are you getting anywhere with the focus event problems? It would be
really useful if you could either fix them or temporarily disable that
part of the code, so that we can run test apps without crashes on
startup.

--=20

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

RE: [java-gnome-hackers] Constructor for org.gnu.gtk.ProgressBar

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

I have added the constructor to ProgressBar.  The need to 
construct a widget from a native handle is prevalent through
the library.  Every method that returns a widget needs
this capability.  I don't like the fact that we have created
these public constructors but I haven't been able to think
of a better solution.

-Jeff

> I'm working on filling out org.gnu.gnome.AppBar.  One of the native
> functions is gnome_appbar_get_progress, which returns a handle to the
> GtkProgressbar used by AppBar.  Is it possible to get a constructor 
> created so that I can construct an ProgressBar widget from 
> the handle?  
> 
> One of the biggest problems is that it would have to be public since I
> need to call it from a org.gnu.gnome package class.  I 
> dislike this kind
> of constructor being public.  Maybe, I can implement
> org.gnu.gtk.ProgressBar's methods in org.gnu.gnome.AppBar and call the
> appropriate Progressbar native calls with the handle returned by
> gnome_appbar_get_progress.  Honestly, I like this even less than the
> public constructor that takes an int for handle.  It defeats the whole
> idea of object oriented programming, but it's a suggestion.
> 
> Does anyone else have any suggestions?  Maybe, the user of 
> our bindings
> doesn't need to use the ProgressBar inside of AppBar.  
> However, I think
> we're going to have to answer this question at some point since there
> are other composite widgets.
> 
> -- 
> Philip A. Chapman
> 

[java-gnome-hackers] Constructor for org.gnu.gtk.ProgressBar

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

I'm working on filling out org.gnu.gnome.AppBar.  One of the native
functions is gnome_appbar_get_progress, which returns a handle to the
GtkProgressbar used by AppBar.  Is it possible to get a constructor=20
created so that I can construct an ProgressBar widget from the handle? =20

One of the biggest problems is that it would have to be public since I
need to call it from a org.gnu.gnome package class.  I dislike this kind
of constructor being public.  Maybe, I can implement
org.gnu.gtk.ProgressBar's methods in org.gnu.gnome.AppBar and call the
appropriate Progressbar native calls with the handle returned by
gnome_appbar_get_progress.  Honestly, I like this even less than the
public constructor that takes an int for handle.  It defeats the whole
idea of object oriented programming, but it's a suggestion.

Does anyone else have any suggestions?  Maybe, the user of our bindings
doesn't need to use the ProgressBar inside of AppBar.  However, I think
we're going to have to answer this question at some point since there
are other composite widgets.

--=20
Philip A. Chapman

Re: [java-gnome-hackers] Init code for gnome.

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

On Sat, 2002-09-07 at 23:10, Philip A. Chapman wrote:
> Everyone,
> 
> I've put the gnome program initialization code in
> org.gnu.gnome.Program.  It is taken almost whole-sale from the old
> GnomeProgram class file.  There are 4 methods which do initialization. 
> initLibgnome0, initLibgnome1, initLibgnomeui0, and initLibgnomeui1. 
> Because initLibgnome0 and initLibgnome1 have the same number and types
> of arguments as initLibgnomeui0 and initLibgnomeui1 (respectively) I
> could not create four constructors.  Therefore, I created a protected
> constructor and four public static methods which will make the
> appropriate native calls, create a new instance of
> org.gnu.gnome.Program, and return it.

I can't wait to look at it.  Keep up the good work.

> I updated TestGNOME to use initLibgnomeui1 through the appropriate
> static method.  It seems to be working in that it can build and display
> the main window.  However, every time I mouse into the window, I get a
> segmentation fault.  Is anyone aware of any issues with the handling of
> mouse events?  The TestGNOME program does not listen for mouse events. 
> I could add it if it would help in the debugging process.

There are several problems with events at the present time.  I am
trying to debug them now.

-Jeff

[java-gnome-hackers] Init code for gnome.

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

Everyone,

I've put the gnome program initialization code in
org.gnu.gnome.Program.  It is taken almost whole-sale from the old
GnomeProgram class file.  There are 4 methods which do initialization.=20
initLibgnome0, initLibgnome1, initLibgnomeui0, and initLibgnomeui1.=20
Because initLibgnome0 and initLibgnome1 have the same number and types
of arguments as initLibgnomeui0 and initLibgnomeui1 (respectively) I
could not create four constructors.  Therefore, I created a protected
constructor and four public static methods which will make the
appropriate native calls, create a new instance of
org.gnu.gnome.Program, and return it.

I updated TestGNOME to use initLibgnomeui1 through the appropriate
static method.  It seems to be working in that it can build and display
the main window.  However, every time I mouse into the window, I get a
segmentation fault.  Is anyone aware of any issues with the handling of
mouse events?  The TestGNOME program does not listen for mouse events.=20
I could add it if it would help in the debugging process.

Thanks,
--=20
Philip A. Chapman

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

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

Sorry.  I wasn't able to get to this today.  I will give
it a try tomorrow.

-Jeff

On Wed, 2002-09-04 at 07:47, Jeffrey Morgan wrote:
> Let me give it a try this morning.  I'll let you know once it
> is in cvs.
> 
> -Jeff
> 
> > 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 
> > JNIEXPORT jint JNICALL
> > Java_org_gnu_gtk_ListStore_gtk_1list_1store_1append (JNIEnv 
> > *env, jclass
> > cls, jint listStore) 
> >   {
> >         GtkListStore *listStore_g = (GtkListStore *)listStore;
> > 		GtkTreeIter *iter_g = (GtkTreeIter *) 
> > g_malloc(sizeof(GtkTreeIter));
> >         {
> >             gtk_list_store_append (listStore_g, iter_g);
> >         }
> > 		return (jint)iter_g;
> >     }
> > 
> > This removed the iter errors. 
> > 
> > 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_1strin
> > g (JNIEnv
> > *env, 
> >         jclass cls, jint listStore, jint iter, jint column, char*
> > strvalue) 
> >     {
> >         GtkListStore *listStore_g = (GtkListStore *)listStore;
> >         GtkTreeIter *iter_g = (GtkTreeIter *)iter;
> >         gint32 column_g = (gint32) column;	
> > 		
> > 		GValue *test;
> >         GValue *value_g = 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). 
> > 
> > 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. 
> > The src/examples/gtk/tree/TreeExample.java is still the current target
> > for testing. 
> > -- 
> > 
> > +----------------------------------------------+
> > | Mark Howard               cam.ac.uk   mh344@ |
> > | http://www.tildemh.com    tildemh.com    mh@ |
> > +----------------------------------------------+
> > 

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

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

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

GTypeInterface, the base class for GtkTreeModel, is the glib 
attempt to provide the equalivant to a Java interface. In my
opinion it is implemented poorly and provides very little
benefit.  GtkTreeModel suffers from some of the problems that
exist in GTypeInterface.  When I have the time I will go
into more details on this topic.

TreeModel wasn't created because when I put together the
defs file for the latest gtk implementation I wasn't quite
sure how to best implement this beast.  I currently believe
that TreeModel should be implemented as an abstract base
class.  We should be able to use the code generator to generate
the class and then make a few manual changes (like making it
abstract).  

-Jeff

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

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

Let me give it a try this morning.  I'll let you know once it
is in cvs.

-Jeff

> 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 
> JNIEXPORT jint JNICALL
> Java_org_gnu_gtk_ListStore_gtk_1list_1store_1append (JNIEnv 
> *env, jclass
> cls, jint listStore) 
>   {
>         GtkListStore *listStore_g = (GtkListStore *)listStore;
> 		GtkTreeIter *iter_g = (GtkTreeIter *) 
> g_malloc(sizeof(GtkTreeIter));
>         {
>             gtk_list_store_append (listStore_g, iter_g);
>         }
> 		return (jint)iter_g;
>     }
> 
> This removed the iter errors. 
> 
> 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_1strin
> g (JNIEnv
> *env, 
>         jclass cls, jint listStore, jint iter, jint column, char*
> strvalue) 
>     {
>         GtkListStore *listStore_g = (GtkListStore *)listStore;
>         GtkTreeIter *iter_g = (GtkTreeIter *)iter;
>         gint32 column_g = (gint32) column;	
> 		
> 		GValue *test;
>         GValue *value_g = 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). 
> 
> 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. 
> The src/examples/gtk/tree/TreeExample.java is still the current target
> for testing. 
> -- 
> 
> +----------------------------------------------+
> | Mark Howard               cam.ac.uk   mh344@ |
> | http://www.tildemh.com    tildemh.com    mh@ |
> +----------------------------------------------+
>