> I think making the desktop a JDesktopPane is the worst way to go, it
> requires to many messy hacks to work could cause problems with AWT
> components and is somewhat small minded design wise. several times Ive
> proposed the use of a Screen.
Actually, after messing with my peer-toolkit hack for long enough, I'm
inclined to agree. Mixing AWT and Swing is just too messy. Of course,
that doesn't mean we have to forgo having PL&F in standard AWT. I think
using the Swing UI delegates directly won't work, because one way or
another they require a JComponent (and probably typecast to whatever
subclass they are working with). Instead, I'm going to investigate
making the L&F pluggable at the peer level. Since our peers will never
make graphics calls directly through native libraries, but instead
through some Screen or GraphicsDevice object, our system is essentially
lightweight. I think I will botch my old code and start some new stuff,
mimicing Swing's idea of the UIManager-JComponent connection in the
Toolkit-Peer connection. Unfortunately, this means that the AWT L&F
will be separate from and independent of the Swing L&F, but I see no
reason why we can't create AWT L&F's that look like the Swing versions.
Then, hypothetically, a user selecting a particular look and feel could
have the two L&F's changed in tandem. Anyway, those are my ideas for
now.
Later,
Sean Cribbs
_______________________________________________
UI maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/ui
