what is the state of awt in lingcj?

Fri Jul 13 16:16:00 GMT 2001

Cedric Berger <cedric@wireless-networks.com> writes:
> Per Bothner wrote:
> > 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.

Of course this approach is useful for the desktop too, as you mention
- I don't think anybody except implementors cares about peers, and
they only because they're supposed to. Though for the desktop we have
the luxury that we can use gtk if we want to and not worry as much
about overhead.
> - no PLAF will mean that very popular development applications (Like JBuilder,
> netbeans, ...) will not work because they all tweak the UI in some ways.

That's not really our concern. JBuilder is non-Free. NetBeans requires
non-Free components, even beyond JDK.
> - no View class will be worse, because you need to subclass View class if you
> want to implement things like "terminal pane", "syntax coloring", ...

Ideally I would like to implement a complete 100%-compatible Free
Swing. That will take years, and I don't see it happening, unless Sun
decides to open-source Swing. Lacking that, the question is whether
there is a 80%-solution-with-20%-of-the-work we can/should aim for.
> 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.

Yes. But they had licensed Swing. We don't have that option.
> I believe the Swing over native-widget is a dead-end solution.

It is certainly not a great solution. But is it a way we can get an
80% solution?
-- 
	--Per Bothner
per@bothner.com http://www.bothner.com/per/