what is the state of awt in lingcj?
Fri Jul 13 14:42:00 GMT 2001
"Rolf W. Rasmussen" <email@example.com> 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.
So I think it is both desirable and reasonable to cheat. A subset
implementation of Swing where the "UI delagate" is just a Gtk object
might be a good starting point. It lets at least simple Swing
programs run, gets us Gnome L&F and themability, and probably has a
lot less overhead. I would also implement AWT using the same way.
Separating out the "model" from the component is more difficult,
though Gnome 2's new text objects should help.
This doesn't really answer the question of how we should use Gtk.
Using Java bindings to Gnome (either Java-Gnome or Gnome-Gtk)
may add an extra layer of overhead: I.e. a Button points to a
ButtonPeer which points to a gnu.gtk.Button which points to a
GtkButton. I really don't want that! So this argues against
both Java-Gnome and Gnome-Gtk, and suggests we should use
hand-written Gtk code for the peer classes - as the current code
seems to do.
More information about the Java