what is the state of awt in lingcj?

Fri Jul 13 15:22:00 GMT 2001

Per Bothner wrote:
> "Rolf W. Rasmussen" <rolfwr@ii.uib.no> writes:
>> > The problem arose when I tried to implement more complex components such
> > as text fields. First then I realized what a terrible state Swing APIs was
> > in. Swing is horribly underspecified. The documentation of a large
> > portion of classes is practically non-existant, and while the design of
> > Swing on the surface may look sound, the further you dig into the details,
> > the more messy it gets. The chances of creating a proper clean room Swing
> > implementation without seems pretty bleak.
>> I would like to have usable and mostly-compatible implementations
> of the Swing components (e.g. JTree) and "models" (e.g. TreeModel).
> I care much less about the UI delegate classes, the PLAF (Pluggable
> Look and Feel) implementation, the text View classes, or in general
> "implementation" classes. I suspect relatively liitle code uses those
> directly, and that's a "experts-only" thing.

I've some problem with theses assumptions. IMHO, there is two different kind
of applications which will benefit from an AWT/SWING application:
1) embedded system with displays (Palm, Java Phones, ...)
2) desktop applications
For embedded applications, Swing is probably too big. What is really needed is
a simple, *peerless* AWT implementation. For theses (embedded) applications,
the best would be to have a "Xlib peer" approch with Java-written peerless
AWT component. This way, embedded developpers would have to reimplement
the basic AWT components (Canevas, Component, Window) but all the widgets
could then be 100% reused.
For desktop application:
 - the same, simple, peerless AWT should be enough to run Yahoo games ;)
 - no PLAF will mean that very popular development applications (Like JBuilder,
 netbeans, ...) will not work because they all tweak the UI in some ways.
 - no View class will be worse, because you need to subclass View class if you
 want to implement things like "terminal pane", "syntax coloring", ...
I don't believe it is possible to implement enough of Swing based on native peers,
(Gtk, Windows, ...).
Look what Apple did: If it was possible, I'm sure they would have implemented
Mac OS X Look and Feel using their native library. But they didn't do it. They
reimplemented the whole L&F using "Pure Java" stuff, and there is many reasons
for that.
I believe the Swing over native-widget is a dead-end solution.
On the other end, I completely agree that a "Desktop" implementation of
AWT/Swing should be properly integrated with the platform GUI system,
and Gnome must be the first priority (with OsX and Win32 second-third
priorities)
Cedric