> what if all your peers subclassed from JComponent? wouldnt that solve
> many of the problems. you create a superclass that does the standard
> configuration for JComponent (seeting isOpaque to true and the like) you
> wouldnt need to change the L&F's in tandem since the peers would be
> linked to the UIManager (I think)
>
Ok, but that's really just a variation on what I tried. It would just
make the peers JComponents themselves instead of owning them. I don't
think that would solve the problems that it has (mainly memory use and
event handling). Right now, I still can't get my old code to work. I
think the toolkit has to be in the bootclasspath, but I'm not sure. It
crashes on startup.
But back on the peers having their own UI delegates, maybe we could make
the UIManager handle those delegates. We'd just create our own look and
feel subclass that defined the keys we want for the new UIs and then the
UIManager could handle them in its normal fashion. Then when the L&F
changes, they would change too. No need for separate L&F's. The only
problem is, if the user selects a Java-based look and feel and not a
JOS-based look and feel, the old values won't change. Maybe this is
desirable or undesirable behavior, I'm not sure.
Any thoughts?
Sean Cribbs
_______________________________________________
UI maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/ui
