Thread: RE: [java-gnome-hackers] Looking forward
Brought to you by:
afcowie
Menu
▾
▴
java-gnome-hackers
|
From: Jeffrey M. <Jef...@Br...> - 2004-01-16 11:56:51
|
Does anybody have any input on this posting? -Jeff > Release 2.5.3 is due Monday and our beta 1 with code freeze is due > one month from Friday.. I would like to start a discussion > on where we > are with current work, what we should try to complete by each of the > milestone dates, and who will be working on each of those tasks. > > Here are my proposals for the items to be completed. I am sure > that I am missing numerous items so please respond and help > me build a complete list. > > complete/debug *Action* and UIManager classes (2.5.3) > implement the new FileChooser class (2.5.4) > update the Menu* classes to reflect the latest gtk (2.5.4) > update of gnome and gnomeui classes to current (beta1) > update all remaining gtk classes to current (2.5.4 through beta1) > fix remaining gconf issues (2.5.4) > update all examples to latest api (release candidate) > update all documentation to latest api (release candidate) > > Please help me complete the list and then we can determine who will > be working on each of the remaining items. > > -Jeff > > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > java-gnome-hackers mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers > |
|
From: Jeffrey M. <Jef...@Br...> - 2004-01-20 12:24:52
|
> > This would be a big help. I could also spend some time with > > you and help you learn the C code if you are interested. It > > really is quite easy. > Of course that I'm interested... How could it be so easy? > I wish I had some good pointers to start with ;) > > -- > Luca De Rugeriis <pie...@li...> Now that 2.5.3 is behind us I will be working on the following for 2.5.4: 1) Fix the last remaining bug with ActionGroup 2) Implement the FileChooser classes 3) Update the Menu* classes 4) Fix any remaining gconf problems Luca, if you are still interested in learning some of the JNI code I could work with you on the FileChooser. -Jeff |
|
From: Luca De R. <pie...@li...> - 2004-01-20 14:32:30
|
Il mar, 2004-01-20 alle 13:24, Jeffrey Morgan ha scritto: > > > This would be a big help. I could also spend some time with > > > you and help you learn the C code if you are interested. It > > > really is quite easy. > > Of course that I'm interested... How could it be so easy? > > I wish I had some good pointers to start with ;) > > > > -- > > Luca De Rugeriis <pie...@li...> > > Now that 2.5.3 is behind us I will be working on the following > for 2.5.4: > > 1) Fix the last remaining bug with ActionGroup > 2) Implement the FileChooser classes > 3) Update the Menu* classes > 4) Fix any remaining gconf problems > > Luca, if you are still interested in learning some of the JNI > code I could work with you on the FileChooser. > That would be great! I was just thinking to take a look at FileChooser (at least to know how it looks;) Remember, however, that I'm with that old pc, and pratically it's impossible for me to compile. I could always do with a simple text editor, but without the possibility to test further changes... I will be happy to work with you and to learn something. Thanks Jeff ;) -- Luca De Rugeriis <pie...@li...> |
|
From: Jeffrey M. <Jef...@Br...> - 2004-01-20 15:26:54
|
> > Luca, if you are still interested in learning some of the JNI
> > code I could work with you on the FileChooser.
> >
> That would be great! I was just thinking to take a look at FileChooser
> (at least to know how it looks;)
> Remember, however, that I'm with that old pc, and pratically it's
> impossible for me to compile. I could always do with a simple text
> editor, but without the possibility to test further changes...
You can do some of the editing and I'll do the testing 8-)
I just added a class FileFilter that needs some native code.
You can start by compiling this file and then running jdk
utility to create the initial JNI header file like:
javah org.gnu.gtk.FileFilter
This will create a file called org_gnu_gtk_FileFilter.h in
the directory where you run it. Copy this file to
gtk/src/jni/org_gnu_gtk_FileFilter.c (notice I changed the
extension from .h to .c). Now the real fun begins!!
The first thing we need to do is update the header and then
convert all of the method decls to method impls.
For the header you can just copy/paste it from another .c file
in the package. This will make sure the file "includes" the
correct headers.
For the methods you can follow the following examples:
Example 1:
.h
JNIEXPORT jint JNICALL Java_org_gnu_gtk_FileFilter_gtk_1file_1filter_1new
(JNIEnv *, jclass);
.c
JNIEXPORT jint JNICALL Java_org_gnu_gtk_FileFilter_gtk_1file_1filter_1new
(JNIEnv *env, jclass cls)
{
return (jint)gtk_file_filter_new();
}
Example 2:
.h
JNIEXPORT void JNICALL
Java_org_gnu_gtk_FileFilter_gtk_1file_1filter_1set_1name
(JNIEnv *, jclass, jint, jstring);
.c
JNIEXPORT void JNICALL
Java_org_gnu_gtk_FileFilter_gtk_1file_1filter_1set_1name
(JNIEnv *env, jclass cls, jint filter, jstring name)
{
gchar* n = (gchar*)(*env)->GetStringUTFChars(env, name, NULL);
gtk_file_filter_set_name((GtkFileFilter*)filter, n);
(*env)->ReleaseStringUTFChars(env, name, n);
}
In the first example we just make a call to a native gtk method
and cast the results to a jint during the return.
In the second example you see that I am calling a JNI method to
read the string from the jstring, calling the native method, and
then freeing the memory used by the gchar*. The filter parameter
is nothing more than a jint that holds the address of the underlying
native struct.
Most methods should be this easy but occasionally you will find a
method that will require more code to convert data types, etc.
Please give this a try and let me know if you get stuck on anything.
-Jeff
|
|
From: Luca De R. <pie...@li...> - 2004-01-21 02:21:39
|
Il mar, 2004-01-20 alle 16:26, Jeffrey Morgan ha scritto:
> > > Luca, if you are still interested in learning some of the JNI
> > > code I could work with you on the FileChooser.
> > >
> > That would be great! I was just thinking to take a look at FileChooser
> > (at least to know how it looks;)
> > Remember, however, that I'm with that old pc, and pratically it's
> > impossible for me to compile. I could always do with a simple text
> > editor, but without the possibility to test further changes...
>
> You can do some of the editing and I'll do the testing 8-)
> I just added a class FileFilter that needs some native code.
> You can start by compiling this file and then running jdk
> utility to create the initial JNI header file like:
>
> javah org.gnu.gtk.FileFilter
>
> This will create a file called org_gnu_gtk_FileFilter.h in
> the directory where you run it. Copy this file to
> gtk/src/jni/org_gnu_gtk_FileFilter.c (notice I changed the
> extension from .h to .c). Now the real fun begins!!
>
> The first thing we need to do is update the header and then
> convert all of the method decls to method impls.
>
> For the header you can just copy/paste it from another .c file
> in the package. This will make sure the file "includes" the
> correct headers.
>
> For the methods you can follow the following examples:
>
> Example 1:
> .h
> JNIEXPORT jint JNICALL Java_org_gnu_gtk_FileFilter_gtk_1file_1filter_1new
> (JNIEnv *, jclass);
>
> .c
> JNIEXPORT jint JNICALL Java_org_gnu_gtk_FileFilter_gtk_1file_1filter_1new
> (JNIEnv *env, jclass cls)
> {
> return (jint)gtk_file_filter_new();
> }
>
>
> Example 2:
> .h
> JNIEXPORT void JNICALL
> Java_org_gnu_gtk_FileFilter_gtk_1file_1filter_1set_1name
> (JNIEnv *, jclass, jint, jstring);
>
> .c
> JNIEXPORT void JNICALL
> Java_org_gnu_gtk_FileFilter_gtk_1file_1filter_1set_1name
> (JNIEnv *env, jclass cls, jint filter, jstring name)
> {
> gchar* n = (gchar*)(*env)->GetStringUTFChars(env, name, NULL);
> gtk_file_filter_set_name((GtkFileFilter*)filter, n);
> (*env)->ReleaseStringUTFChars(env, name, n);
> }
>
>
> In the first example we just make a call to a native gtk method
> and cast the results to a jint during the return.
>
> In the second example you see that I am calling a JNI method to
> read the string from the jstring, calling the native method, and
> then freeing the memory used by the gchar*. The filter parameter
> is nothing more than a jint that holds the address of the underlying
> native struct.
>
> Most methods should be this easy but occasionally you will find a
> method that will require more code to convert data types, etc.
>
> Please give this a try and let me know if you get stuck on anything.
Thanks Jeff!
Your explanation was great and really of use ;)
I'm sorry I couldn't reply earlier, but real life has taken me away.
Generating the headers then converting from decls to impls sounds smart!
I'm going to try the thing, you made the concept clear, it just a matter
of taking care about C syntax and rules, something I'm not used to ;)
--
Luca De Rugeriis <pie...@li...>
|
|
From: Jeffrey M. <ku...@zo...> - 2004-01-21 02:26:54
|
Please let me know when you need help. I am more than happy to spend all of the time necessary to help you learn the JNI code. -Jeff On Tue, 2004-01-20 at 21:19, Luca De Rugeriis wrote: > Thanks Jeff! > Your explanation was great and really of use ;) > I'm sorry I couldn't reply earlier, but real life has taken me away. > Generating the headers then converting from decls to impls sounds smart! > I'm going to try the thing, you made the concept clear, it just a matter > of taking care about C syntax and rules, something I'm not used to ;) |
|
From: Jeffrey M. <Jef...@Br...> - 2004-01-22 13:53:13
|
Luca, are you interested in writing any of the JNI code for the FileChooser classes? If not, I will go ahead and complete them over the next few days. -Jeff > Please let me know when you need help. I am more than > happy to spend all of the time necessary to help you > learn the JNI code. > > -Jeff > > On Tue, 2004-01-20 at 21:19, Luca De Rugeriis wrote: > > Thanks Jeff! > > Your explanation was great and really of use ;) > > I'm sorry I couldn't reply earlier, but real life has taken me away. > > Generating the headers then converting from decls to impls > sounds smart! > > I'm going to try the thing, you made the concept clear, it > just a matter > > of taking care about C syntax and rules, something I'm not > used to ;) > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > java-gnome-hackers mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers > |
|
From: Luca De R. <pie...@li...> - 2004-01-23 01:42:39
|
Il gio, 2004-01-22 alle 14:53, Jeffrey Morgan ha scritto: > Luca, are you interested in writing any of the JNI code for the > FileChooser classes? If not, I will go ahead and complete them > over the next few days. I'm really sorry for that! I was thinking it wasn't so urgent. As I said I haven't j-g compiled now, but anyway I was trying to write that JNI code until I discovered that javah need the .class file, which I can't produce at the moment. Again I'm sorry that you was relying on me to commit the code and I'm afraid you have to do without me this time :( Now some good news: today I've ordered my new workstation and a broadband connection !! ;) So, in few days, I'll come back at full throttle... eheh, give the geeks more power ;) -- Luca De Rugeriis <pie...@li...> |
|
From: Luca De R. <pie...@li...> - 2004-01-23 01:58:13
|
Il ven, 2004-01-23 alle 02:44, Luca De Rugeriis ha scritto: > Il gio, 2004-01-22 alle 14:53, Jeffrey Morgan ha scritto: > > Luca, are you interested in writing any of the JNI code for the > > FileChooser classes? If not, I will go ahead and complete them > > over the next few days. Jeff, I want to apologize for that, and it would be great if you could complete the code for the FileChooser ;) You can take it as I was without pc. Ok I can send mails etc... I also have jdk, and I could even compile j-g-0.8.2 (in a couple of hours). But for the head version I need gnome too, and this is definitely overwhelming. Everything I had download and compiled in the past is on my girlfriend's pc, and bringing stuff from there would be impractical. This is just to explain my situation clearly, not that I want you to know the details of my life ;) As I said in the other mail, the situation is going to get better, really. -- Luca De Rugeriis <pie...@li...> |
|
From: Jeffrey M. <Jef...@Br...> - 2004-01-23 11:43:14
|
> Il gio, 2004-01-22 alle 14:53, Jeffrey Morgan ha scritto: > > Luca, are you interested in writing any of the JNI code for the > > FileChooser classes? If not, I will go ahead and complete them > > over the next few days. > I'm really sorry for that! I was thinking it wasn't so > urgent. As I said > I haven't j-g compiled now, but anyway I was trying to write that JNI > code until I discovered that javah need the .class file, which I can't > produce at the moment. Again I'm sorry that you was relying on me to > commit the code and I'm afraid you have to do without me this time :( That's OK. You are just going to miss out on some of the fun. > Now some good news: today I've ordered my new workstation and a > broadband connection !! ;) So, in few days, I'll come back at full > throttle... > eheh, give the geeks more power ;) |
|
From: Jeffrey M. <Jef...@Br...> - 2004-04-06 11:51:53
|
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. |
|
From: Luca De R. <pie...@fa...> - 2004-04-08 15:55:11
|
Il mar, 2004-04-06 alle 13:51, Jeffrey Morgan ha scritto: > > > 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 agree with Mark: do you remember how many bug reports we have had when we released 0.8.2 (and joined the official bindings)? We couldn't take care of our users whining for a 0.8.3 release, cause we were in business with 2.5.3. > 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. I think, maybe, we should look more to the practical aspect...(really no offense intended:)) We should ask ourselves: do we need 64-bit support? Who is going to use it in the near future? Is someone managing to build a useful app with it? (well not that I want a promise of faith but maybe someone could have been hired to write something with it (like Bob Fischer with the iPaq...)) What I say is that if we are going to add 64 bit support only because having it is fine, perhaps we could work on the existing code to fill the holes that are present in the bindings, instead. (like DnD...) In this way, I hope we'll see more applications spreading out, cause our users will have a stronger and more complete library to play with. My point is that it's better to keep fixing bugs for the 2.6 release while our users will ask for them. Then we could accept patches for the 0.8 branch but we should explicitly encourage people to use 2.6, because of the large changes that have been done. I'm tempted to say that Jeff, Mark and Jonas could take the devel branch, and work on adding new modules , on keeping in sync with gnome,and on adding 64bit support (if it's really needed), because this is the more work, while the others and I should maintain the stable branch (with a lot of help from you of course...:)). But since I understand that, at least Mark and I are a bit under pressure with the uni, I don't know if this idea could fit at the moment... So maybe the best solution now is to wait until the gnome-2.7 release cycle to add new modules and 64bit support. In this way we can start from a heavily fixed version of j-g-2.6.X without the need of backporting anything. When the 2.7 branch will start, then I could take care of backporting eventual fixes in the 2.6, but since it has just passed a six months bug-busting period, hopefully there will be few bugs to fix between 2.7 and 2.8. > > > 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. I would take care of fixing the stable branch, and I think this implies also implementing DnD...but are you talking about to get it fixed *before* we release final? Because, unfortunately, I will find a bit of time only after 17th. I hope my thoughts weren't much confusing, and sorry if something come across wrong: I only want to help, really! OT:did anybody watch "revolution os"? I think it's a "must" :) -- Luca De Rugeriis <pie...@fa...> |
|
From: Jeffrey M. <Jef...@Br...> - 2004-04-09 11:34:46
|
> I agree with Mark: do you remember how many bug reports we > have had when > we released 0.8.2 (and joined the official bindings)? > We couldn't take care of our users whining for a 0.8.3 > release, cause we > were in business with 2.5.3. Perhaps a good compromise is for us to target a 2.6.1 release one month from the release of 2.6.0. During that time we can just focus on the Lazy Event Registration, GDK enhancements, gconf enhancements and bug fixes. We would not create a branch in the code until that release went out. > I think, maybe, we should look more to the practical > aspect...(really no offense intended:)) > We should ask ourselves: do we need 64-bit support? Who is > going to use > it in the near future? Is someone managing to build a useful app with > it? (well not that I want a promise of faith but maybe someone could > have been hired to write something with it (like Bob Fischer with the > iPaq...)) > What I say is that if we are going to add 64 bit support only because > having it is fine, perhaps we could work on the existing code to fill > the holes that are present in the bindings, instead. (like DnD...) > In this way, I hope we'll see more applications spreading > out, cause our > users will have a stronger and more complete library to play with. My main concern is that the 64-bit fix will be fairly intrusive into our code. I fear that the longer we wait the more difficult this change will become. If everybody feels we should put this off then I am ok with that. > My point is that it's better to keep fixing bugs for the 2.6 release > while our users will ask for them. Then we could accept > patches for the > 0.8 branch but we should explicitly encourage people to use > 2.6, because > of the large changes that have been done. > > I'm tempted to say that Jeff, Mark and Jonas could take the devel > branch, and work on adding new modules , on keeping in sync with > gnome,and on adding 64bit support (if it's really needed), > because this > is the more work, while the others and I should maintain the stable > branch (with a lot of help from you of course...:)). > But since I understand that, at least Mark and I are a bit under > pressure with the uni, I don't know if this idea could fit at the > moment... > So maybe the best solution now is to wait until the gnome-2.7 release > cycle to add new modules and 64bit support. In this way we can start > from a heavily fixed version of j-g-2.6.X without the need of > backporting anything. When the 2.7 branch will start, then I > could take > care of backporting eventual fixes in the 2.6, but since it has just > passed a six months bug-busting period, hopefully there will > be few bugs > to fix between 2.7 and 2.8. The majority of the bugs that will be found will need to be fixed in 2.7 and 2.6. We clearly need somebody on the team appointed the stable release maintainer. This person will need to backport fixes to the 2.6 branch and make periodic releases. I think this should not be a full time effort so this person could also work on the development releases when not working on stable releases. This would start after the release of 2.6.1 (around the middle of May). > I would take care of fixing the stable branch, and I think > this implies > also implementing DnD...but are you talking about to get it fixed > *before* we release final? Because, unfortunately, I will > find a bit of > time only after 17th. I think DnD is something we should try to get working during the 2.7 development effort. Here I am talking about both Widget and TreeView DnD. There is already a lot of code here but it is incomplete. We should also add Clipboard support as well. -Jeff 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. |
|
From: Luca De R. <pie...@fa...> - 2004-04-09 13:23:52
|
Il ven, 2004-04-09 alle 13:34, Jeffrey Morgan ha scritto: > > I agree with Mark: do you remember how many bug reports we > > have had when > > we released 0.8.2 (and joined the official bindings)? > > We couldn't take care of our users whining for a 0.8.3 > > release, cause we > > were in business with 2.5.3. > > Perhaps a good compromise is for us to target a 2.6.1 release > one month from the release of 2.6.0. During that time we can > just focus on the Lazy Event Registration, GDK enhancements, > gconf enhancements and bug fixes. We would not create a branch > in the code until that release went out. I totally agree with this point. > > > I think, maybe, we should look more to the practical > > aspect...(really no offense intended:)) > > We should ask ourselves: do we need 64-bit support? Who is > > going to use > > it in the near future? Is someone managing to build a useful app with > > it? (well not that I want a promise of faith but maybe someone could > > have been hired to write something with it (like Bob Fischer with the > > iPaq...)) > > What I say is that if we are going to add 64 bit support only because > > having it is fine, perhaps we could work on the existing code to fill > > the holes that are present in the bindings, instead. (like DnD...) > > In this way, I hope we'll see more applications spreading > > out, cause our > > users will have a stronger and more complete library to play with. > > My main concern is that the 64-bit fix will be fairly intrusive > into our code. I fear that the longer we wait the more difficult this > change will become. If everybody feels we should put this off then > I am ok with that. I really can't say, because I'm not very into this...but I feel the we need to improve the current code (as users ask for it) instead of introducing 64bit support. However I'd prefer to hear some others opinions. > > My point is that it's better to keep fixing bugs for the 2.6 release > > while our users will ask for them. Then we could accept > > patches for the > > 0.8 branch but we should explicitly encourage people to use > > 2.6, because > > of the large changes that have been done. > > > > I'm tempted to say that Jeff, Mark and Jonas could take the devel > > branch, and work on adding new modules , on keeping in sync with > > gnome,and on adding 64bit support (if it's really needed), > > because this > > is the more work, while the others and I should maintain the stable > > branch (with a lot of help from you of course...:)). > > But since I understand that, at least Mark and I are a bit under > > pressure with the uni, I don't know if this idea could fit at the > > moment... > > So maybe the best solution now is to wait until the gnome-2.7 release > > cycle to add new modules and 64bit support. In this way we can start > > from a heavily fixed version of j-g-2.6.X without the need of > > backporting anything. When the 2.7 branch will start, then I > > could take > > care of backporting eventual fixes in the 2.6, but since it has just > > passed a six months bug-busting period, hopefully there will > > be few bugs > > to fix between 2.7 and 2.8. > > The majority of the bugs that will be found will need to be fixed > in 2.7 and 2.6. We clearly need somebody on the team appointed > the stable release maintainer. This person will need to backport > fixes to the 2.6 branch and make periodic releases. I think this > should not be a full time effort so this person could also work > on the development releases when not working on stable releases. > This would start after the release of 2.6.1 (around the middle of > May). Ok, I think, at that time, I'll have no problem picking up the stable branch. > > I would take care of fixing the stable branch, and I think > > this implies > > also implementing DnD...but are you talking about to get it fixed > > *before* we release final? Because, unfortunately, I will > > find a bit of > > time only after 17th. > > I think DnD is something we should try to get working during > the 2.7 development effort. Here I am talking about both > Widget and TreeView DnD. There is already a lot of code here > but it is incomplete. We should also add Clipboard support as > well. Ok, I've got the idea and I agree with you. We'll work on DnD and friends during 2.7 release cycle. -- Luca De Rugeriis <pie...@fa...> |
|
From: Luca De R. <pie...@li...> - 2004-01-17 19:36:52
|
Il ven, 2004-01-16 alle 12:56, Jeffrey Morgan ha scritto: > Does anybody have any input on this posting? > > -Jeff I'm sorry Jeff couldn't reply faster, and thanks for the credit in the authors file. At the moment I'm stuck with an old pentium 200mhz that is a pain to use :( but I'm about to upgrade my hardware. I hope I'll get the new stuff in about 2 weeks. It means that it takes me like a couple of hours to j-g. (apart from compiling gnome libs). So I think I have to wait.... > > Release 2.5.3 is due Monday and our beta 1 with code freeze is due > > one month from Friday.. I would like to start a discussion > > on where we > > are with current work, what we should try to complete by each of the > > milestone dates, and who will be working on each of those tasks. OK. > > Here are my proposals for the items to be completed. I am sure > > that I am missing numerous items so please respond and help > > me build a complete list. > > > > complete/debug *Action* and UIManager classes (2.5.3) > > implement the new FileChooser class (2.5.4) > > update the Menu* classes to reflect the latest gtk (2.5.4) > > update of gnome and gnomeui classes to current (beta1) > > update all remaining gtk classes to current (2.5.4 through beta1) > > fix remaining gconf issues (2.5.4) > > update all examples to latest api (release candidate) I'll help with each one of these items, but since, for now, can't write C code, I think it's better to decide case by case. Be sure that I could write the most of the public interfaces.(I haven't tried with listeners yet...) I could also provide some examples. > > update all documentation to latest api (release candidate) I could do it with javadocs, but for the tutorial, a native speaker is better. > > > Please help me complete the list and then we can determine who will > > be working on each of the remaining items. > > I think it's quite complete, we also have the TODO.gtk file. |
|
From: Jeffrey M. <ku...@zo...> - 2004-01-17 22:03:59
|
On Sat, 2004-01-17 at 14:37, Luca De Rugeriis wrote: > Il ven, 2004-01-16 alle 12:56, Jeffrey Morgan ha scritto: > I'm sorry Jeff couldn't reply faster, and thanks for the credit in the > authors file. > At the moment I'm stuck with an old pentium 200mhz that is a pain to use > :( but I'm about to upgrade my hardware. I hope I'll get the new stuff > in about 2 weeks. > It means that it takes me like a couple of hours to j-g. (apart from > compiling gnome libs). So I think I have to wait.... I hope you get a nice one!! > > > Here are my proposals for the items to be completed. I am sure > > > that I am missing numerous items so please respond and help > > > me build a complete list. > > > > > > complete/debug *Action* and UIManager classes (2.5.3) > > > implement the new FileChooser class (2.5.4) > > > update the Menu* classes to reflect the latest gtk (2.5.4) > > > update of gnome and gnomeui classes to current (beta1) > > > update all remaining gtk classes to current (2.5.4 through beta1) > > > fix remaining gconf issues (2.5.4) > > > update all examples to latest api (release candidate) > I'll help with each one of these items, but since, for now, can't > write C code, I think it's better to decide case by case. > Be sure that I could write the most of the public interfaces.(I haven't > tried with listeners yet...) > I could also provide some examples. This would be a big help. I could also spend some time with you and help you learn the C code if you are interested. It really is quite easy. > > update all documentation to latest api (release candidate) > I could do it with javadocs, but for the tutorial, a native speaker is > better. I should be able to update the tutorial after the code freeze. > > > > > Please help me complete the list and then we can determine who will > > > be working on each of the remaining items. > > > > I think it's quite complete, we also have the TODO.gtk file. I added a new section at the end of the TODO.gtk file listing all items that need to be updated as I start a code comparison between java-gnome and the latest gtk/gnome libs. These are what I mean when I stated: > > update all remaining gtk classes to current (2.5.4 through beta1) -Jeff |
|
From: Luca De R. <pie...@li...> - 2004-01-17 23:06:00
|
Il sab, 2004-01-17 alle 22:53, Jeffrey Morgan ha scritto: > On Sat, 2004-01-17 at 14:37, Luca De Rugeriis wrote: > > Il ven, 2004-01-16 alle 12:56, Jeffrey Morgan ha scritto: > > I'm sorry Jeff couldn't reply faster, and thanks for the credit in the > > authors file. > > At the moment I'm stuck with an old pentium 200mhz that is a pain to use > > :( but I'm about to upgrade my hardware. I hope I'll get the new stuff > > in about 2 weeks. > > It means that it takes me like a couple of hours to j-g. (apart from > > compiling gnome libs). So I think I have to wait.... > > I hope you get a nice one!! I'm aiming at some quite fast hardware :) > > > > Here are my proposals for the items to be completed. I am sure > > > > that I am missing numerous items so please respond and help > > > > me build a complete list. > > > > > > > > complete/debug *Action* and UIManager classes (2.5.3) > > > > implement the new FileChooser class (2.5.4) > > > > update the Menu* classes to reflect the latest gtk (2.5.4) > > > > update of gnome and gnomeui classes to current (beta1) > > > > update all remaining gtk classes to current (2.5.4 through beta1) > > > > fix remaining gconf issues (2.5.4) > > > > update all examples to latest api (release candidate) > > I'll help with each one of these items, but since, for now, can't > > write C code, I think it's better to decide case by case. > > Be sure that I could write the most of the public interfaces.(I haven't > > tried with listeners yet...) > > I could also provide some examples. > > This would be a big help. I could also spend some time with > you and help you learn the C code if you are interested. It > really is quite easy. Of course that I'm interested... How could it be so easy? I wish I had some good pointers to start with ;) -- Luca De Rugeriis <pie...@li...> |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X