Hi, On Wed, 2004-03-03 at 01:19, Arnaud Vandyck wrote: > If Red Hat is willing to give the > work back to the community (I hope they'll do), the demo was really > good. If the promises will never be available it would be *very* > frustrating.
Everything is out there <http://sources.redhat.com/eclipse/> no trickery used during the demonstration. I actually compiled everything from source to make sure that the demo was real. You can have a native Eclipse on your Debian box now (through alien to convert the gcc-ssa, runtime and native-eclipse rpms to debs). The real problem is incorporating all the changes into the different code bases "upstream". To be honest I believe this must be a bit frustrating for some of the hackers who work both for Red Hat on some of this stuff and also for the different projects like gcc. They had to make some horrible hacks for their corporate masters so they have something that at least works for them, but they cannot accept those ugly workarounds when they are wearing their GNU maintainers hat. Everybody that wants to help cleaning up some of the ugly hacks is appreciated (contact [EMAIL PROTECTED] for more info) > But I can understand Red Hat spending a lot of money to finish awt and > swing (I heard this, is it true?) Yes, some Red Hat hackers help a lot with trying to finish the standard java GUI core library parts. But they are not the only once working on it. It truly is a cooperative effort. I have attached an email I sent to the classpath mailinglist yesterday but which seemed to have never arrived (looks like some of those new Windows virusses are hitting the gnu.org mail servers very hard). It shows where we are at the moment and where we want to go in the future. > they maybe want to be the first > distribution to provide a complete free java alternative. Debian does > not have this problem. I'd be really happy if we can provide a complete > free java alternative six month later (it would be no problem for > me!)... but I hope it'll take less time ;-) (and it'll be available for > the community). Come on :) Show a bit more spirit! We might want to cooperate together with the other distributions. But that shouldn't mean they can just beat us to the punch! Cheers, Mark
--- Begin Message ---Hi all, The following is an email I send to some people wanting to help out with Swing. It is probably a good idea to post it to the list so others also know about the current status of the current efforts with respect to getting a free Swing implementation for GNU Classpath, gcj and other free runtimes. If you are looking for things to help out with then this email will contain lots of hints! I do want to add that even though I am extremely happy we are now making real progress on this front, it is still a lot of work. Even if we can keep the current rapid progress it will take many months before we will have something people can reliably use (for Swing, AWT is in a pretty good shape now). And as noted below not all of AWT and Swing is covered yet. Please don't recommend Swing to anybody except to say that if they already have free software written that currently uses non-free Swing implementation to contact us to see how we can help migrate the application to what we are working on. (For new applications that need a GUI, I would recommend the java-gnome bindings that will be part of the next Gnome 2.6 release. (http://www.gnome.org/start/2.5/bindings/ and http://java-gnome.sf.net/) The approach we are taking is making sure that we have a AWT build upon GTK+ peers (which is the most important peer implementation we want at the moment since it integrates so nicely with the rest of the GNU system). The AWT (peer) Components are mostly functional already. Testing is done with the visual-tester in Mauve (http://sources.redhat.com/mauve/). There is also a simple TestAWT program in the classpath source tree of which you can see a screenshot: http://www.klomp.org/mark/classpath/awt-04-03-2004.png Other non-component parts of AWT are not yet implemented completely, or have some stubs at the moment. These are java.awt.color, java.awt.datatransfer, java.awt.dnd, java.awt.im.*. Help on these is really appreciated. GTK+/freedesktop.org has libraries for cut & paste, drag & drop, and internationalization that can/should probably be used for some of these. The other big problem area is java.awt.image.*. If you want to work on that package please ask on the list what the current plans are (Thomas Fitzsimmons will probably coordinate this). Swing is implemented on top of AWT and the java 2D (java.awt.geom) classes that Graydon Hoare previously created (on top of the cairo library from freedesktop.org). Although our current Swing implementation doesn't really use java 2D at all. http://people.redhat.com/~graydon/native-java2d-aug28-2003.png Some parts (JList, JProgressBar, JSeparator, JButton and JLabel) are starting to work, there is still a lot to do. But we are now seeing daily progress. See for example the following two screenshots: http://people.redhat.com/~graydon/free-swing-feb-09-2004.png http://people.redhat.com/~graydon/free-swing-feb-25-2004.png (Graydon, it would be nice if you could put the sample programs to produce the above pictures online so others can directly play with it.) Red Hat has recently been helping with working on the java GUI technology (AWT and Swing). To make it easier for the Red Hat hackers to work together on this without disrupting the other developers, which are concentrating on other parts of the library, we have setup a CVS branch for gcc/libjava (which hosts the libgcj library that gcj uses). This work will be integrated into the main libgcj and GNU Classpath tree once parts are finished and the code has been checked to make sure it complies with our coding standards. This will happen aprox once a month. The first merge will probably take place on March 12, after the 0.08 release. For more detailed info and what to check out when you want to help with this effort please see the following two mailinglist threads: http://gcc.gnu.org/ml/java/2004-02/msg00063.html http://mail.gnu.org/archive/html/classpath/2004-02/msg00022.html Sascha Brawer has, independent from the above effort, implemented the javax.swing.border and javax.swing.undo frameworks. He also created a big test-suite for this package which has been added to the Mauve, a collaborative effort to write a free test suite for the java core class libraries (http://sources.redhat.com/mauve/). We currently don't have people working on the javax.swing.text package or the html and rtf subpackages which provide support for advanced text components and working with html and rtf documents. Although Michael Koch has some javax.swing.text fixes to at least get some simpler programs using it compiling/running. To get a wider perspective on GNU Classpath please take a look at the presentation that Sascha Brawer and I gave at FOSDEM last week when you want to get a more detailed understanding of the current status and goals. "GNU Classpath: Core Classes for a Diversity of Java Virtual Machines" http://dandelis.ch/people/brawer/articles/classpathFeb2004/ Finally Patrik Reali has put together a GNU Classpath Task List which can be found at http://www.gnu.org/software/classpath/tasks.html. We hope the task list will help people pick up both smaller and larger things to work on when they want to help with GNU Classpath. Cheers, Mark
signature.asc
Description: This is a digitally signed message part
--- End Message ---
signature.asc
Description: This is a digitally signed message part
