On Tue, 23 Sep 2003 18:47:28 +0200 Clemens Eisserer <[EMAIL PROTECTED]> wrote:
> Hi there! > > >Nope. GNU Classpath AWT integrating should happen for the 1.1.3. > > > Does this mean the current kaffe-xawt implementation will be thrown away? Not at all. We already support multiple AWTs -- this would just be another one, I imagine. > This was the best awt implemenation I´ve every seen, and I dont > understand why gnu-classpath isnt based on this awt. I think it comes down to ownership/licensing dynamics (eg. Transvirtual never transferred copyrights to the FSF for the AWT). > The only problem are the ugly widget L&F´s, but should be possible to > make this whole thing skinable without big troubles. Yeah, the L&F is definitely ugly. :-) I haven't done too much AWT stuff myself, but I think we could serve as a useful place to experiment with AWT integration since we have somewhat looser licensing constraints than other projects. Here's what I'd like to see: 1) Multiple AWT implementations a) Some using "lightweight widgets", where the widgets are drawn in Java. eg: - our current X AWT - Swing (we can run Sun's old AWT based one, and should be able to run their newer Java2D based one if we get a Java2D implementation) - others, eg. Rudolph (from Wonka) The Transvirtual version of Kaffe had a lot of additional AWT work done on it. The big thing was it had a lightweight AWT that could render to a "no-native-wm" backend, which provided a pluggable backend for the core graphics primitives on a number of platforms (X, Linux framebuffer (using the fgl library), Wind River's UGL, GRX, MGL, Allegro). The "no-native-wm" backend sounds similar in concept in many ways to what Java2D does - it might make sense to move that stuff into a Java2D implementation. There is probably additional window-manager functionality that Java2D doesn't cover. Transvirtual's AWT and Swing both provide support for skins / L&F's. As far as backends go, I think it would be cool to experiment with even more extreme Java-only solutions, eg. driving a framebuffer as a Java byte array, or writing a xlib completely in Java! Graphics backends are really interesting, because the challenges involved in utilizing modern graphics acceleration hardware are interesting. Things like Cairo and DirectFB on Linux, DirectX on Windows, and Quartz on Mac OS X provide use ways to get access to accelerated hardware. If we had a really good Java2D implementation, it might even be feasible to use something like WeirdX as a more flexible replacement for XFree86 to support legacy apps. :-) b) Some using "native widgets". These provide tighter integration on some platforms. - Gtk - nice for Gnome desktops. There's a version of Gtk which will render to the framebuffer too. - Qt and Qt/Embedded - Win32 (for Windows) - there was a MicroWindows AWT for Kaffe based on the Win32 widgets, I think. - a Carbon based AWT for Mac OS X would be nice - Motif/Lesstif would be interesting, just because it's what Sun used in their original AWT - SWT apparently works, which works with Win32, Motif, and Gtk. It would be cool to do a SWT backend that used lightweight widgets. Note that some of these widget sets are themeable themselves, and can use multiple backends as well. eg. Qt is essentially a lightweight widget set that renders it's own widgets on the platforms it supports. Conceivably, it could even be made to use a Java2D backend. :-) 2) Compile-time switching of AWTs All these AWTs should be configurable at "configure" time. For embedded platforms, it's nice to be able to select only one specific AWT tuned to the target platform. Transvirtual took this to extremes with fgl, where even the color depth was chosen at configure time. 3) Run-time switching of AWTs It would be nice to be able to configure Kaffe with multiple AWTs, and have them selectable at runtime using a property. If somebody wanted to do something even more extreme, I imagine that it would be possible to create and API to enable applications to use multiple AWT implementations simultaneously. :-) Sascha Brawer is organizing a free Java AWT BOF at Linux Kongress - that should be interesting: http://www.linux-kongress.org/2003/bofs/index.html Anyways, I don't think there is a "one-size-fits-all" solution for graphics on Java - I'd like to keep an open mind, and hope some really nice interfaces and implementations evolve. Cheers, - Jim _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe