java-gnome-hackers

[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

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