I'm
talking full AWT peer implementation (which would allow Swing to work
on top of it).
I'm
also looking into creating some adapter classes to convert Swing components into
SWT, so the look and feel is SWT. Personally, I'm very against using
Swing inside Eclipse, as it completely screws up the consistent look and feel of
the IDE. Adapter classes would have the same interface as Swing and use SWT
components under the covers. (This may have to be an 80% solution though, as
there are some things you can do in Swing that you cannot do in
SWT).
I'm trying to figure out the right way to deal with the L&F
issue. Eclipse looks and feels great, and I want it to stay that way without
becoming a frankengui by becoming infected with Swing-based
plugins...
-- Scott
I'm curious. Define "here", in the "really wouldn't work here"
bit. Are you trying to implement enough AWT to get a recent vintage
Swing running or something? Or just other > AWT 1.1,
non-Swing features.
>I've been working on one, and got it partly working. Getting it to
work as a >plugin has been challenging wrt classloaders. I chatted with
some of the >Instantiations folks at JavaOne, and I think we came up
with an idea to make >the classloaders work. I'll see if I can try it
out this coming weekend. > >BTW: The OTI
implementation for VA Micro that keeps coming up really >wouldn't work
here. I've looked into it and it's not complete (I believe it >assumes
J2ME personal config, which is rather limited), and wasn't really
a >peer setup. > >--
Scott
|