Sean Cribbs wrote:
> 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.
well I dont know about memory use and event handling but from my
experience with Swing I think that it would handle the L&F problem but I
dont know if its the best way per se
> 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.
Im sure most users would consider this a bug and a "turn off" the power
users would have long worked around it but there not the ones we need to
make this a success in the classic definition
Cheers,
DigiGod
_________________________
[EMAIL PROTECTED]
AIM:DigiGod 86
_________________________
Quote of the Moment:
No, I'm Canadian. It's like an American, but without a
gun.
-Dave Foley
_________________________
Prank of the Moment:
Using the conferencing feature of your office phone, dial
one Induhvidual, then while it's ringing dial another and
conference them together. Put your own phone on mute
and listen to see how long they'll make small talk before
figuring out that neither one placed the call.
O-
_______________________________________________
UI maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/ui
