Le 15 févr. 05, à 01:34, M. Uli Kusterer a écrit :
At 22:08 Uhr +0000 14.02.2005, Nicolas Roard wrote:
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.
I will accept it for the first release I think ;-)… Nicolas is it ok
for you ?
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 ?
yep, you are probably right, I was just thinking the -update
notification would be useful to avoid the need to relaunch GNUstep
applications when you change the current theme to have it taken in
account… And I thought in some cases, it could permit to produce
various pixmaps for a theme from a very simple set of basic pixmaps,
but Nicolas is right : it is probably just an extra layer of complexity
for non really needed flexibility.
For the -update notification, I'm thinking now we can problably just do
it internally inside Camaelon by flushing the pixmaps cache and the
visible windows display… ?
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
