RE: [java-gnome-hackers] Looking forward

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

The 64-bit support and lazy event registration are global in
nature so I had hoped that we might be able to address these
first in the next development cycle.  Once that was finished
the focus could be on completing a couple of the current
bindings and making the changes to keep up with the GNOME
team

> On Wed, Mar 31, 2004 at 07:48:10AM -0500, Jeffrey Morgan wrote:
> > I hope between now and the next beta we can focus on testing the
> > current code base and fixing many of the bugs reported on 
> Sourceforge.
> 
> I have ported my bugwatcher application to java-gnome cvs and 
> it is now
> working perfectly. The latest changes fixed it. 

This is good news.  There still are a few bugs I am chasing
down prior to the final beta release.

> > 1) 
> I think keeping in sync with native libraries and fixing bugs 
> should be
> our top priority - it should be ok as long as we stay on top of it. 
> 
> In terms of fixing bugs, how long do you think we should wait before
> creating a new cvs branch to separate stable/unstable releases? I
> suspect we will have a lot of new people using java-gnome and finding
> new bugs. Backporting fixes to each branch is hard work, so 
> I'd suggest
> we leave it as long as possible before making a branch. 

I personally would like to make the branch soon after 2.6 because I
wish to attach the 64-bit issue and really shouldn't do this in a
"stable" branch.  A question we should ask ourselves is "should we only
provide bug fixes for the 2.6 release and forward or should we also
provide bug fixes for the 0.8 branch?".  We also need to agree on a process
we can use to keep the stable branches up to date.  Please let me know
what you think.

> 
> > 2) Lazy Event Registration - Both Jonas and Mark have suggested this
> > change.  It makes a lot of sense and should be a nice performance
> > improvement.
> IMHO, the only performance problem java-gnome has is the start up time
> of the jvm, which we can't change. So I'd say this might be lower
> priority. 

I think this is more than just a performance fix.  It is a much cleaner
implementation and should be a simple change to make.  Since this
change impacts many classes in the project I personally would like to get it
out of the way early in the development cycle.  Perhaps Jonas can implement
this item.  What do you think Jonas?

> libgnome-panelapplet has been requested a few times. 

This will require Bonobo support.  Adding Bonobo to java-gnome will be a
fairly large undertaking and I was hoping to put it off until the next
release cycle.  If everybody feels this is more important then we can
postpone gnome-vfs support until later and start work on Bonobo and then
the panelapplet.

> I would also like to see full drag and drop support for treeviews. It
> might be possible now, but AFAIK, it hasn't been done.

I think we need to appoint somebody in charge of drag and drop.  It
does not work throughout the bindings but I believe it is very close
to working 8-)  Somebody please take this task.

> Now for the bad news.. I'm not sure that I can do anything 
> for the start
> of the 2.7 series. I really must concentrate on uni work 
> more. My final
> final exams finish in June so hopefully things will get better after
> then. 

We are sad to hear this but understand your priorities.  Please let
us know how things are doing and we look forward to your help in June.

> 
> -- 
>   .''`. Mark Howard
>  : :' :
>  `. `'  http://www.tildemh.com 
>    `-   mh...@de... | mh...@ti... | mh...@ca... 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
> 

 NOTE: THIS IS A CONFIDENTIAL COMMUNICATION. This transmission is intended
only for the use of the individuals or entity to which it is addressed. If
you are not the intended recipient, or the person responsible for delivering
the message to the intended recipient, please return or delete it
immediately. Although this e-mail and any attachments are believed to be
free of any virus or other defect, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by us for
any loss or damage arising in any way from its unauthorized modification or
use.