Le 14 févr. 05, à 19:09, M. Uli Kusterer a écrit :
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.
Well may be we should keep your IKIcon implementation on Mac OS X
identical, but for GNUstep, because we can have a better implementation
I would like to have it, in order to allow with IKIcon instance stuff
like : 1 lock icon over 1 TextEdit icon over 1 Text icon (for a IconKit
produced "locked TextEdit document icon")… More on this below.
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.
We are back to the idea I discussed with Nicolas initially to have a
more modular architecture with a separated CompositorKit which
implements basic multi-layered image format support and manipulations
(could be useful ofr many pictures related applications), probably with
a class like NSCompositeImage (it shouln't be a subclass of NSImage),
and then the IconKit would rely on a specific subclass of
NSCompositeImage which should be the current IKIcon class.
Then Camaelon wouldn't probably bother with IconKit but only with
CompositorKit which would send notifications when packaged images are
updated.
What do you think ?
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
