Le 14 févr. 05, à 21:41, Quentin Mathé a écrit :
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.
Well, actually there's a lot of time you could want a more complex
composition than just 1 icon + 1 badge.. for example, you can have 1
default background + 1 "icon" + 1 foreground (could be the "twirling"
page part..) + 1 badge ...
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.
well, while I think a "compositor" object could be useful for Camaelon,
I doubt the kind of compositions capacities needed by Camaelon will be
really useful for IconKit.. don't know..
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 ?
That's a possibility, but I'm not sure having a separate
"CompositorKit" it's worth the work. Plus Camaelon have absolutely no
need of notificiations at the "image" level, that would be too much.
I don't know, I think the kind of compositions we want for IconKit are
pretty basic.. hmm.. I guess you have a point -- we *could* use such a
Compositor in Camaelon. But i'm not sure it's worth the trouble..
--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke
