Hi all, After all the GUI (AWT/Swing) work going on in CVS it is probably a good idea to give a little overview of the process.
Thomas Fitzsimmons gave a very inspiring talk on "GCJ and the Desktop" at the Desktop Developers' Conference describing our AWT, Swing and java-gnome support. Slides and screenshots at http://people.redhat.com/fitzsim/ddc2004/ A report by Christopher Blizzard can be found at http://www.0xdeadbeef.com/html/2004/07/#200407201126 MERGING. We decided that it was very important to share these advances to our AWT and Swing code faster with the other projects so this last week we made sure that the libgcj gui branch and GNU Classpath CVS have been (almost) completely merged. Kaffe has merged the AWT and Swing code again from GNU Classpath into Kaffe CVS and jamvm (1.1.4) and kissme (CVS) can be made to work out of the box with the new GNU Classpath CVS gui code. Starting immediately we are going to start merging between the libgcj gui branch and GNU Classpath CVS directly and more frequently. Any future work in [gnu]/java[x]/(awt/swing)/ and native/jni/gtk-peer directories should go directly to the libgcj gui branch or GNU Classpath CVS, *not* gcc trunk, since this will ease integration and reduce the risk of a merge clobbering changes. We used to do merges like: kaffe/[other-projects] <=> classpath <=> libgcj <=> gui-branch Since most changes for java/awt, javax/swing and native/jni/gtk-peers take place on the gui branch we will now do it like: kaffe/[other-projects] <=> classpath <=> gui-branch <=> libgcj at least for those (sub)dirs. (Note that doesn't mean you cannot develop gui stuff directly on GNU Classpath CVS, but if you do either check it also in on the gui-branch, or ask someone to do that for you.) I used to be a bit skeptical about splitting off the gui work on a separate branch. But these days more and more people seem to have no problem just working with the branch directly. Thomas his jhbuild setup even makes it fun and easy to do: http://people.redhat.com/fitzsim/gcj-and-jhbuild.html And I noticed that being able to just use gdb with native gcj/C/JNI code is invaluable for debugging at least the gtk-peers. Tom Tromey setup a comparison script to show the things not completely merged yet between GNU Classpath and libgcj. For the non-gui parts (libgcj head) see: http://gcc.gnu.org/java/libgcj-classpath-compare.html For the GUI parts (against libgcj gui-branch) see: http://gcc.gnu.org/java/gui-compare/libgcj-classpath-compare.html Jim Pick has offered us some shared resources for the GNU Classpath, gcj and kaffe projects so we will setup a similar comparison script against kaffe soon. (And we will then also be able to setup a developer.classpath.org environment to make it easier to do testing, autobuilding, scripting and generating dynamic webpages.) Of course we hope to get both gcj and kaffe working out of the box with GNU Classpath (CVS). This is a slow process though. Hopefully for gcj the BC-ABI work will make this easier. And Guilhem has recently switched kaffe to use the GNU Classpath VMObject and VMThread platform interfaces to be able to share more low level code. EXAMPLES. To make it easier to show off all the nice new GUI work we now have a new examples directory. The idea is that we will distribute a small collection of example code to show what can be done with the GNU Classpath library. The first examples included are the old TestAWT and Test code merged into a AWTDemo and the activityboard and testswing code merged into a SwingDemo. This is how it currently looks (actually it looks a bit better now against GNU Classpath CVS from today, the screenshots are already old!): http://www.klomp.org/mark/classpath/awtdemo-2004-jul-25.png http://www.klomp.org/mark/classpath/swingdemo-2004-jul-25.png When you do a make && make install a precompiled examples.zip and all the source code will be installed in ${prefix}/share/classpath/examples to play with. See the examples/README for more information. This is not just for GUI code though. It should be easy to add new examples (IODemo, NetDemo, BeanDemo, CollectionsDemo, RegexDemo, RMIDemo, NIODemo, TextDemo, SQLDemo, MathDemo, GeomDemo, ...) by just adding a new directory under gnu/classpath/examples/ in the examples dir and to add a Demo.java (and possibily some helper classes). Also when gcj 3.5 is out we want to include examples of how to create native binaries directly. BUGS. Red Hat had an internal bug database with AWT and Swing related issues for libgcj. These have all been exported to the public bugzilla on gcc.gnu.org (both old and resolved bugs and new still open bugs). I made sure that all AWT and SWING related issues in the savannah tracker are now also mirrored there. The gcc.gnu.org bugzilla maintainer setup a special AWT and SWING component for us to keep track of both bugs and new features people want to work on. Please coordinate and list missing issues at: http://gcc.gnu.org/bugzilla/buglist.cgi?component=AWT http://gcc.gnu.org/bugzilla/buglist.cgi?component=SWING For everything else please keep using the savannah bug tracker: https://savannah.gnu.org/bugs/?group=classpath (Bugzilla support for Savannah will hopefully come in the future.) NOT MERGED YET. The main gui things not merged yet between libgcj and GNU Classpath are the build infrastructure to get the Cairo Graphics2D backend working (all code is already in the tree). And libgcj has a xlib AWT peers backend which has not yet been merged into GNU Classpath (it seemed wiser to concentrate on the GTK+ AWT peers and get them 100% perfect first). As always, volunteers to help with this are welcome! Happy hacking! Mark
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
