At 12:49 Uhr +0000 14.02.2005, Nicolas Roard wrote:
if we want "live" update we need some kind of tracking, yes..
But I don't think we're limited to two composited icons.. you can
have an icon resulting of a lot more compositions than that..
IconKit is built so that one IKIcon can only be composited from two
others. However, you can of course composite yet another icon onto an
already composited icon, and so on, ad infinitum. It's a tad less
convenient, but a) I did it this way because it's how Apple's Icon
Services do it, and b) because it will simplify our implementation a
lot.
Hmm, actually, using a separate composition object is a good idea
for Camaelon !
(instead the actual bunch of class methods used for the composition
of the pixmaps... and it should simplify the caching design...)
But I'm not sure Camaelon should use IKIcon anyway -- seems a bit
bloat, no ? IKIcon's job is doing icons.
If the only thing you want is notification, anyway, I doubt it's
efficient (for Camaelon) to have the notification handled at the
"element" level -- you want a general notification, period.
I'd also feel a little odd using IKIcon for theming controls. Since
themes should probably be allowed to reposition parts of a control
(e.g. a theme may want to have scroll arrows at a different position,
or the "popup icon" on a popup button at the left, or whatever), I'd
think we'd need a more flexible approach than what we have for icons.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
