[kaffe] Planning for 1.1.2 release - XAWT obsolete?

[Jim Pick]

On Tue, 23 Sep 2003 18:47:28 +0200
Clemens Eisserer <linuxhippy at web.de> 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