At 22:08 Uhr +0000 14.02.2005, Nicolas Roard wrote:
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 ...
That is *already* possible. The way it works right now is that you call:
IKIcon* myIcon = [IKIcon iconForFile: @"/path/to/TextFile.txt"];
IKIcon* badgedIcon = [myIcon
iconByAddingIcon: [IKIcon iconWithIdentifier:
IKIconLinkBadge] toRect: [IKIcon
badgeRectForPosition:
IKBadgePositionStandardLink]];
badgedIcon = [myIcon iconByAddingIcon:
[IKIcon iconWithIdentifier: IKIconLockedBadge]
toRect: [IKIcon badgeRectForPosition:
IKBadgePositionStandardLocked]];
// etc...
I.e. you get the icon for file X, then create a
new icon that looks like that with a "link"
arrow, and then you take the icon for file X
+"link" arrow and create a new one that badges a
lock icon on top of that.
Of course, the icon provider may already have
applied a few badges to the icon of a particular
file by itself and given you that when you
requested the icon for file X in the first place.
The advantage of this is that we don't have to
keep a list of all the icons and compositing
modes and rects used for each composition in
IKIcon. It only needs to remember two of them.
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..
What does Camaeleon need special compositing
facilities for? If it is just for themeing, I'd
think that all it would do is draw a few images
in a rect, and it'd probably tile them more often
than actually draw overlapping stuff. I don't
think I understand what you are talking about
here ?
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..
I'd be willing to try to help, if someone told
me what we're talking about ;-) Any example,
perhaps?
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
