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

RE: [java-gnome-hackers] First pass at libglade signal connecting

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

> I fixed the mapping layer, which had to map signal names and not
> listener method names.  Libglade should now basically work with GTK
> components.  Four pieces are not implemented yet:

Great.  I look forward to taking a look later today 8-)


> 1.  GNOME widget support, and I need a question answered:  the
> package-private EventMap class that was added to org.gnu.gtk either
> needs to be copied into org.gnu.gnome, or it needs to be 
> moved somewhere
> common, such as org.gnu.glib.  The problem with making it 
> common is that
> it has to then be public, and it's strictly an implementation 
> class.  Is
> it sufficient to document that it's only to be used by this
> implementation?  I'd rather not duplicate code, but I also 
> don't want an
> implementation class to become part of the official public API.

I think making it public in the glib package is the best approach.
I would not want to duplicate this in the gnome package either.


> 2.  Support for Glade's drop-down list of signal handlers, 
> which allows
> a developer to map a signal directly to a GTK function, such 
> as mapping
> a Window's destroy signal to gtk_main_quit().  I'm not sure how
> important this is since Python's libglade doesn't appear to support
> these handlers, but they aren't hard to add if you folks feel 
> they'll be
> used.

I personally don't think these will be used.  I would like to
hear from the other developers on this one.

> 4.  Write tests and examples.

Good!!

[java-gnome-hackers] Misc things

[RUBIOJR <RU...@te...>]

Hi folks.

I've the vte bindings ready to be commited. Although they need much 
more work, they are fully usable now.

Before I commit the code I want to modify the build.xml and the make 
stuff so the bindings can be compiled correctly. I've already added 
things to the build.xml to compile the vte java classes. The new 
targets are build-vte and vte-jar. I also fixed some build.xml bugs 
which prevented ant from behaving properly. The java code was always 
compiled because ant searched the compiled classes in the wrong 
directory. The java classes were up to date, but ant compiled again al 
the code because it couldn't find the already compiled ones.

I'm now trying to fix the configure and make stuff, getting it ready to 
compile the vte part, but It's difficult for me. What do you think 
about making the build process for the native things independent from 
the java sources build process ? I mean, using make to build with gcc 
and after that, calling ant manually to build the java code. IMHO this 
would make the scripts easier and smaller and we could use the ant 
properties in the command line to switch between jikes, modern or gcj.

I need a piece of advice.

Thanks.

Rubio Jr. 

Re: [java-gnome-hackers] First pass at libglade signal connecting

[Tom B. <Tom...@Su...>]

> 1.  GNOME widget support, and I need a question answered:  the
> package-private EventMap class that was added to org.gnu.gtk either
> needs to be copied into org.gnu.gnome, or it needs to be moved somewhere
> common, such as org.gnu.glib.  The problem with making it common is that
> it has to then be public, and it's strictly an implementation class.  Is
> it sufficient to document that it's only to be used by this
> implementation?  I'd rather not duplicate code, but I also don't want an
> implementation class to become part of the official public API.

One more point regarding this:  if EventMap is moved to org.gnu.glib and
made public, then the addEventHandler methods which Jeffrey wanted to
get away from can be made package-private.  In fact, since EventMap only
uses one, the other five variations can be deleted.

Tom

[java-gnome-hackers] Libglade stubs file generator checked in

[Tom B. <Tom...@Su...>]

> 3.  A Java implementation skeleton generator, which is a utility that
> reads a Glade definition file and generates a Java file with stubs for
> the referenced handlers.  

Done.  In src/bin is LibGladeStubs, which reads a Glade 2.0 XML file and
creates a Java source file with stubs for the handler methods specified
in the glade file.  It also has a main so that once the stub bodies are
written the app can be run.

Tom

Re: [java-gnome-hackers] First pass at libglade signal connecting

[Tom B. <Tom...@Su...>]

I fixed the mapping layer, which had to map signal names and not
listener method names.  Libglade should now basically work with GTK
components.  Four pieces are not implemented yet:

1.  GNOME widget support, and I need a question answered:  the
package-private EventMap class that was added to org.gnu.gtk either
needs to be copied into org.gnu.gnome, or it needs to be moved somewhere
common, such as org.gnu.glib.  The problem with making it common is that
it has to then be public, and it's strictly an implementation class.  Is
it sufficient to document that it's only to be used by this
implementation?  I'd rather not duplicate code, but I also don't want an
implementation class to become part of the official public API.

2.  Support for Glade's drop-down list of signal handlers, which allows
a developer to map a signal directly to a GTK function, such as mapping
a Window's destroy signal to gtk_main_quit().  I'm not sure how
important this is since Python's libglade doesn't appear to support
these handlers, but they aren't hard to add if you folks feel they'll be
used.

3.  A Java implementation skeleton generator, which is a utility that
reads a Glade definition file and generates a Java file with stubs for
the referenced handlers.  

4.  Write tests and examples.

Let me know if I've missed any to-do items here.

Tom

Re: [java-gnome-hackers] First pass at libglade signal connecting

[Tom B. <Tom...@Su...>]

On Thu, 2002-11-28 at 23:14, Tom Ball wrote:
> The problem I'm facing is that the new event mappings squish all signals
> into one listener interface method, so there's no way currently for
> libglade to be able to separate them again, unless a large table gets
> defined that maps event types back to signals.  

Forget this, as it should work as implemented.  I need to debug what's
going on here...

[java-gnome-hackers] First pass at libglade signal connecting

[Tom B. <Tom...@Su...>]

The current build has a new example, src/examples/glade/Example1.java,
which demonstrates how a simple applet can be connected with a signal
handler.  Check out the SignalHandler class, as it uses the
java.lang.reflect.Proxy class to create event listener implementations
on the fly; I've always wanted to kick the tires on that class, and
found it surprisingly easy to use.

The problem I'm facing is that the new event mappings squish all signals
into one listener interface method, so there's no way currently for
libglade to be able to separate them again, unless a large table gets
defined that maps event types back to signals.  

Any ideas on how I can map this efficiently?  Otherwise it looks like
going back to using GObject.addEventHandler may make more sense.

Tom

RE: [java-gnome-hackers] Implementation change to GTK classes

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

This looks like a great solution.  I look forward
to seeing the code in cvs.

> On Tue, 2002-11-26 at 10:34, Tom Ball wrote:
> Missed a statement:
> 
>     protected void initializeEventHandlers() {
> =>      super.initializeEventHandlers();
>         evtMap.initialize(this);
>     }
> 
> Perhaps initializeEventHandlers should be moved into GObject...
> 
> Tom
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T 
> handheld. Power & Color in a compact size! 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
> 

Re: [java-gnome-hackers] Implementation change to GTK classes

[Tom B. <Tom...@Su...>]

On Tue, 2002-11-26 at 10:34, Tom Ball wrote:
Missed a statement:

    protected void initializeEventHandlers() {
=>      super.initializeEventHandlers();
        evtMap.initialize(this);
    }

Perhaps initializeEventHandlers should be moved into GObject...

Tom

[java-gnome-hackers] Implementation change to GTK classes

[Tom B. <Tom...@Su...>]

Libglade needs to map signals to event listener classes on a per-class
basis.  To avoid developing a separate table for these mappings (which
makes maintenance harder), I have augmented the information already in
the classes which handle events (if you can think of a better way,
please let me know).  Note: this change doesn't affect any public API,
nor how event handling is actually managed.

Currently, classes which handle events all have a protected method
called initializeEventHandlers().  Each class implements this as:

    protected void initializeEventHandlers() {
        super.initializeEventHandlers();  // optional
        addEventHandler(<signal>, <handler>, this);
        addEventHandler(<signal>, <handler>, this);
        // etc.
    }

Although no map object is actually used, these addEventHandler
statements provide the mapping I need to extend.  This is done by
creating a private static EventMap instance and storing this information
plus the event listener class in it.  The above code then looks like:

    protected void initializeEventHandlers() {
        evtMap.initialize(this);
    }

    private static EventMap evtMap = new EventMap();
    static {
        evtMap.addEvent(<signal>, <handler>, <listener_class>);
        evtMap.addEvent(<signal>, <handler>, <listener_class>);
        // etc.
    }

    public static String getListenerClass(String signal) {
        return evtMap.getListenerClass(signal);
    }

The EventMap class looks like this:

/*package-private*/class EventMap {

    private List events = new ArrayList();

    private class Entry {
	String signal;
	String method;
	String listenerClass;
	Entry(String s, String m, String l) {
	    signal = s;
	    method = m;
	    listenerClass = l;
	}
    }

    void addEvent(String signal, String method, String listenerClass) {
	events.add(new Entry(signal, method, listenerClass));
    }

    /**
     * Connect all event handlers to this event source.
     */
    void initialize(GObject source) {
	Iterator i = events.iterator();
	while (i.hasNext()) {
	    Entry e = (Entry)i.next();

            /* All GTK addEventHandler calls specify source twice
             * (the object being invoked and as a cbrev parameter).
             * This should probably be eliminated to for performance.
             */
	    source.addEventHandler(e.signal, e.method, source);
	}
    }

    /**
     * Return the name of the event listener class for a given signal.
     */
    String getListenerClass(String signal) {
	Iterator i = events.iterator();
	while (i.hasNext()) {
	    Entry e = (Entry)i.next();
	    if (e.signal.equals(signal))
		return e.listenerClass;
	}
	return null;
    }
}

Yes, it is called a Map but uses a List, but that doesn't matter because
the List and its interface is completely private.  If this impacts
performance in any way, it can be changed later to be an array.  I chose
to make initialization faster than listener lookup, since there are
going to be a lot more widget creations than libglade lookups.

If no one complains in a day or so, I'll check these in.

Tom

Re: [java-gnome-hackers] Connection strategy

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

Sorry for being so short and unclear.  What I was referring to was
the fact that the connect method of LibGlade uses the addEventHandler
method to connect a callback to any provided method and object as
long as they meet the signal callback signature.  What I would like
to see is for the libglade to bind callbacks to listeners in a
similar fashion to the remainder of the library.  At this point
I have no design in mind.

On Sun, 2002-11-24 at 16:29, Tom Ball wrote:
> > One of the areas that I would like to see changed in the libglade 
> > binding is the event handling.  As you can see from our 
> > bindings we have just changed over to a more "java like" 
> > event handling API.  libglade still wants to use the old 
> > signal_connect method.  As a result I have had to keep our 
> > old event handling structure public.
> 
> I don't find any explicit signal_connect references; would you please
> tell me what API I should avoid?  Better yet, rip out anything you don't
> want used (or print a deprecated warning when the function is called),
> and I'll work around it.  I'll be able to streamline connection once I
> know what areas to avoid.
> 
> Tom
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
> 

[java-gnome-hackers] Connection strategy

[Tom B. <Tom...@Su...>]

> One of the areas that I would like to see changed in the libglade 
> binding is the event handling.  As you can see from our 
> bindings we have just changed over to a more "java like" 
> event handling API.  libglade still wants to use the old 
> signal_connect method.  As a result I have had to keep our 
> old event handling structure public.

I don't find any explicit signal_connect references; would you please
tell me what API I should avoid?  Better yet, rip out anything you don't
want used (or print a deprecated warning when the function is called),
and I'll work around it.  I'll be able to streamline connection once I
know what areas to avoid.

Tom

Re: [java-gnome-hackers] Missing GTK Constructors?

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

Those constructors have been added on an as needed basis.
Feel free to add them wherever you need.

On Sat, 2002-11-23 at 16:52, Tom Ball wrote:
> Now that libglade is starting to come up, I'm having problems creating
> widgets because of what appears to be missing constructors in many
> classes.  I need to create a Java instance of a widget where I have a
> native handle, something like "Foo(int handle)".  Questions:
> 
> . Is this constructor form intentionally missing?  
>   . If so, how do I create such widgets?  
>   . If not, do you mind my adding the missing constructor to the 
>     classes Glade can create?
> 
> Tom
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
> 

[java-gnome-hackers] Missing GTK Constructors?

[Tom B. <Tom...@Su...>]

Now that libglade is starting to come up, I'm having problems creating
widgets because of what appears to be missing constructors in many
classes.  I need to create a Java instance of a widget where I have a
native handle, something like "Foo(int handle)".  Questions:

. Is this constructor form intentionally missing?  
  . If so, how do I create such widgets?  
  . If not, do you mind my adding the missing constructor to the 
    classes Glade can create?

Tom

[java-gnome-hackers] Cool icons

[<ru...@dr...>]

Hi all. A friend of mine has made three cool icons to use it on the java-gnome web site.

http://arkuin.dragon-lance.net/java-gnome-logo.png
http://arkuin.dragon-lance.net/java-gnome.png
http://arkuin.dragon-lance.net/coffee.png

I hope we can use one of them instead of the current java-gnome icon.

regards,
ç
Rubio Jr.

RE: [java-gnome-hackers] Configure patched

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

> Hi. Configure is now patched temporarily. It's a really ugly 
> path but it
> works for me and I hope it works for you too. I need more time to work
> on it so we can generate the configure file properly. 
> 
> I would like to include a --with-jikes option too. Do you 
> like the idea?

Yes!

[java-gnome-hackers] Configure patched

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

Hi. Configure is now patched temporarily. It's a really ugly path but it
works for me and I hope it works for you too. I need more time to work
on it so we can generate the configure file properly.=20

I would like to include a --with-jikes option too. Do you like the idea?

Send me feedback.

Thanks.

--=20
Sergio Rubio <ser...@hi...>

RE: [java-gnome-hackers] Gcj detection

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

> Ok I see. I use debian and this is my output:
>=20
> gcj (GCC) 3.2.1 20021111 (Debian prerelease)
> Copyright (C) 2002 Free Software Foundation, Inc.
> Esto es software libre; vea el c=F3digo para las condiciones de=20
> copia.  NO
> hay
> garant=EDa; ni siquiera para MERCANTIBILIDAD o IDONEIDAD PARA=20
> UN PROP=D3SITO
> EN
> PARTICULAR
>=20
> Now that I know the reason, I will try to solve it.

Great!

RE: [java-gnome-hackers] Gcj detection

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

Ok I see. I use debian and this is my output:

gcj (GCC) 3.2.1 20021111 (Debian prerelease)
Copyright (C) 2002 Free Software Foundation, Inc.
Esto es software libre; vea el c=F3digo para las condiciones de copia.  NO
hay
garant=EDa; ni siquiera para MERCANTIBILIDAD o IDONEIDAD PARA UN PROP=D3SIT=
O
EN
PARTICULAR

Now that I know the reason, I will try to solve it.

Thanks.


El mi=E9, 20-11-2002 a las 23:07, Jeffrey Morgan escribi=F3:
> Not a dumb question.  If you are using RH8 gcj will not work
> with java-gnome.  Type 'gcj --version' and you will see the
> the version banner has changed.  This command used to just
> print the version.  This is why the gcj build will not work.
> We need to add a task to our list.
>=20
> > Hi. Has anyone tried to build the bindings with gcj recently? I've
> > gcc-3.2 installed but configure doesn't detect it.=20
> > Sorry about this dumb question.
> >=20
> > Thanks.
> >=20
> > --=20
> > Sergio Rubio <ser...@hi...>
> >=20
--=20
Sergio Rubio <ser...@hi...>

RE: [java-gnome-hackers] Gcj detection

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

Not a dumb question.  If you are using RH8 gcj will not work
with java-gnome.  Type 'gcj --version' and you will see the
the version banner has changed.  This command used to just
print the version.  This is why the gcj build will not work.
We need to add a task to our list.

> Hi. Has anyone tried to build the bindings with gcj recently? I've
> gcc-3.2 installed but configure doesn't detect it. 
> Sorry about this dumb question.
> 
> Thanks.
> 
> -- 
> Sergio Rubio <ser...@hi...>
> 

[java-gnome-hackers] Gcj detection

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

Hi. Has anyone tried to build the bindings with gcj recently? I've
gcc-3.2 installed but configure doesn't detect it.=20
Sorry about this dumb question.

Thanks.

--=20
Sergio Rubio <ser...@hi...>

RE: [java-gnome-hackers] Error reporting

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

This is an excellent topic.  Thank you for bringing it up Tom.
Currently we do not have a consistent approach for handling
errors.  Some methods return null, some methods throw exceptions,
and some methods do no error checking at all (leading to
NullPointerExceptions at runtime).  I personally like the proactive
Exception approach.  What does everybody else think?  We should
also discuss the creation of a package to contain java-gnome
specific exceptions if this is the approach we plan to take.

> Jeffrey,
> 
> The Jackpot project has a project review this Friday which will decide
> what I'll be working on going forward at Sun Labs (happily 
> the layoff ax
> passed over most of us).  We've been in firedrill mode the past few
> weeks, but next week I'll be able to devote more time to the libglade
> work and can give you a reasonable schedule.
> 
> One general question belongs on your list, unless it's already been
> decided:  how should exceptional conditions be handled?  Libglade, for
> example, follows the normal C library convention of returning 
> NULL from
> its "read and parse the glade file" routine, but doesn't provide any
> sort of other feedback to the developer (unless they having logging
> enabled and check the log).  Is that the convention for all of
> java-gnome?
> 
> My preference is to map likely problems to existing or new exception
> classes.  For libglade, that includes checking that the file exists
> (FileNotFoundException), that it can be read successfully 
> (IOException)
> and that it contains a valid XML description (new 
> GladeXMLException).  I
> don't want to require a different coding style than the rest of
> java-gnome, however.
> 
> To make these exceptions more useful, I have almost working code that
> "catches" the message logged by the libglade-2.0 library and uses that
> the message of the thrown exception.  If exception mapping is 
> chosen for
> the whole project, I should be able generalize this code and make it a
> common utility function somewhere.
> 
> The reason I bring up exception handling is that not having 
> them now and
> then changing policies later can frustrate our clients.  I comfortable
> with either C-style or Java-style error handling, as long as its
> consistent across our libraries.
> 
> Tom
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: To learn the basics of securing 
> your web site with SSL, click here to get a FREE TRIAL of a Thawte 
> Server Certificate: http://www.gothawte.com/rd524.html
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
> 

[java-gnome-hackers] Error reporting

[Tom B. <Tom...@Su...>]

Jeffrey,

The Jackpot project has a project review this Friday which will decide
what I'll be working on going forward at Sun Labs (happily the layoff ax
passed over most of us).  We've been in firedrill mode the past few
weeks, but next week I'll be able to devote more time to the libglade
work and can give you a reasonable schedule.

One general question belongs on your list, unless it's already been
decided:  how should exceptional conditions be handled?  Libglade, for
example, follows the normal C library convention of returning NULL from
its "read and parse the glade file" routine, but doesn't provide any
sort of other feedback to the developer (unless they having logging
enabled and check the log).  Is that the convention for all of
java-gnome?

My preference is to map likely problems to existing or new exception
classes.  For libglade, that includes checking that the file exists
(FileNotFoundException), that it can be read successfully (IOException)
and that it contains a valid XML description (new GladeXMLException).  I
don't want to require a different coding style than the rest of
java-gnome, however.

To make these exceptions more useful, I have almost working code that
"catches" the message logged by the libglade-2.0 library and uses that
the message of the thrown exception.  If exception mapping is chosen for
the whole project, I should be able generalize this code and make it a
common utility function somewhere.

The reason I bring up exception handling is that not having them now and
then changing policies later can frustrate our clients.  I comfortable
with either C-style or Java-style error handling, as long as its
consistent across our libraries.

Tom

Re: [java-gnome-hackers] update and TODOs

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

I Like it. I will have the vte bindings at the end of this month. Also I
want to make the UML of all the bindings after working in vte.=20

El mar, 19-11-2002 a las 16:15, Jeffrey Morgan escribi=F3:
> I have been working on the Gnome classes over the past week.  I have most
> of the classes working.  I still have a couple of problems with the UIInf=
o
> implementation that I plan to address today.  Going forward I hope to
> add the event handling to the gnome package and thought about creating
> a org.gnu.gnome.event package similar to the gtk equivalent. =20
>=20
> I thought it might be a good idea to list all of the tasks that should=20
> be completed prior to our next release.  I would also like to take this
> one step further and define the future direction and goals of this projec=
t.
> I am including my spontaneous attempt to define the tasks and direction.
> I am sure I am missing some important tasks so please add additional=20
> tasks or comment on the ones I have listed.  Also, if you are working on=20
> one of these tasks or wish to work on a task let the team know so we=20
> don't duplicate efforts.
>=20
> As for the future direction, I have included my ideas below.  I would lik=
e=20
> for use to get on a schedule of having a release every couple of months. =
 My
> ultimate goal is to provide more than just a wrapper over native widgets.
> I hope to eventually provide an entire framework for developing Gnome
> applications.  I propose a target of having release 1.0 ready by late nex=
t=20
> summer.  I cannot achieve this goal without your help.  Let me know=20
> your thoughts.
>=20
>=20
> Major TODOs for next release
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
> 1) Complete the event handling for the gnome package - Jeff
> 2) Complete the implementation of ItemFactory in the gtk package
>    This should be implemented using a similar approach to the
>    UIInfo classes. - ?
> 3) Complete the vte implementation (Rubio, what is your estimate?)
> 4) Complete the glade updates (Tom, what is your estimate?)
> 5) Enhance the current examples to demonstrate a more complete usage
>    of the widgets.  We also need to write new examples to demonstrate
>    the new widgets in the libraries. - ?
> 6) Fix the delete event propagation - Jeff
> 7) Update the tutorial - Jeff
> 8) Update all remaining documentation. - ?
> 9) Translate the documentation into Spanish - Alberto
>=20
>=20
> Future direction
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> 0.8 - This is our first version that supports GTK/Gnome 2.  This is also =
a
> major rewrite of the bindings.
> In this release we provid a wrapper around the native libraries.
> 0.8.1 - Bug fixes, enhancements to the gnome canvas implementation,
> enhancements to the gdk
> drawing classes.
> 0.8.2 - Bug fixes, better gconf integration, enhancements to the atk and
> pango implementation
> 0.8.3 - Bug fixes, bonobo implementation, gnomeprint implementation
> 0.9 - First release of the framework
> 0.9.1 - Framework enhancements
> 0.9.2 - Framework enhancements
> 0.9.3 - Framework enhancements
> 1.0 - First production ready release of the bindings.  From this point
> forward we will maintain
> API stability.
>=20
> -Jeff
>=20
>=20
--=20
:: Rubio Jr. ::
ser...@hi...
http://rubiojr.dragon-lance.net

::  GrULLA   ::
http://grulla.hispalinux.es


" The number 1 tip for GTK+ programming is: =20

  - Don't use C; In my opinion, C is a library programming language
    not an app programming language. "
								=09
                                                  Owen Taylor.

 =20

[java-gnome-hackers] update and TODOs

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

I have been working on the Gnome classes over the past week.  I have most
of the classes working.  I still have a couple of problems with the UIInfo
implementation that I plan to address today.  Going forward I hope to
add the event handling to the gnome package and thought about creating
a org.gnu.gnome.event package similar to the gtk equivalent.  

I thought it might be a good idea to list all of the tasks that should 
be completed prior to our next release.  I would also like to take this
one step further and define the future direction and goals of this project.
I am including my spontaneous attempt to define the tasks and direction.
I am sure I am missing some important tasks so please add additional 
tasks or comment on the ones I have listed.  Also, if you are working on 
one of these tasks or wish to work on a task let the team know so we 
don't duplicate efforts.

As for the future direction, I have included my ideas below.  I would like 
for use to get on a schedule of having a release every couple of months.  My
ultimate goal is to provide more than just a wrapper over native widgets.
I hope to eventually provide an entire framework for developing Gnome
applications.  I propose a target of having release 1.0 ready by late next 
summer.  I cannot achieve this goal without your help.  Let me know 
your thoughts.


Major TODOs for next release
============================
1) Complete the event handling for the gnome package - Jeff
2) Complete the implementation of ItemFactory in the gtk package
   This should be implemented using a similar approach to the
   UIInfo classes. - ?
3) Complete the vte implementation (Rubio, what is your estimate?)
4) Complete the glade updates (Tom, what is your estimate?)
5) Enhance the current examples to demonstrate a more complete usage
   of the widgets.  We also need to write new examples to demonstrate
   the new widgets in the libraries. - ?
6) Fix the delete event propagation - Jeff
7) Update the tutorial - Jeff
8) Update all remaining documentation. - ?
9) Translate the documentation into Spanish - Alberto


Future direction
===========
0.8 - This is our first version that supports GTK/Gnome 2.  This is also a
major rewrite of the bindings.
In this release we provid a wrapper around the native libraries.
0.8.1 - Bug fixes, enhancements to the gnome canvas implementation,
enhancements to the gdk
drawing classes.
0.8.2 - Bug fixes, better gconf integration, enhancements to the atk and
pango implementation
0.8.3 - Bug fixes, bonobo implementation, gnomeprint implementation
0.9 - First release of the framework
0.9.1 - Framework enhancements
0.9.2 - Framework enhancements
0.9.3 - Framework enhancements
1.0 - First production ready release of the bindings.  From this point
forward we will maintain
API stability.

-Jeff