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 LF´s, but should be possible to
make this whole thing skinable without big troubles.
Yeah, the LF 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 / LF'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
