Le 13 févr. 05, à 16:10, M. Uli Kusterer a écrit :
Basically, IKIcon on GNUstep is a thin wrapper around NSImage, plus
some code for badge position calculation, plus what's left of
IKIconCompositor. There's no caching right now except what NSImage may
be doing in GNUstep's AppKit. But I'll probably move that back in once
I've worked out a scheme on how to clean up old, unused icons from
time to time.
ok
Next stop on this track would be to take the icon-lookup code from
your first IconKit and make IKIcon's -initForFile: and
-initWithExtension:mimeType:attributes: call upon that to get its
images. Should we build the icon provider into IKIcon (as a few
class-methods), or do you want a separate (GNUstep-specific) class to
provide the icons? Whatever we do, the class providing the images
should probably also maintain the cache of IKIcons indexed by file
type and application identifier or so.
I would like separate class(es) similar to what it is now.
We may also want to use that other call GNUstep has for getting
standard images instead of imageNamed:.
Which other calls ?
I'd love to hear your comments at this point, because now we're at
the point where it's probably most obvious to see where I'm going with
this, and where I will be doing work that isn't of use at all to my
own MacOS X work, and thus would be 100% pointless if you later find
it doesn't work for you.
ok.
In IKIconIdentifier.h :
extern IKIconIdentifier IKIconTrashFolder; <-- we should have
IKIconRecyclerFolder for GNUstep too
extern IKIconIdentifier IKIconTrashFolderFull; <-- idem
// ...
extern IKIconIdentifier IKIconSymLinkBadge; <-- I would prefer
IKIconLinkBadge because they are the only sort of links the user should
be able to manipulate in Finder/Workspace, except Alias-like link but
they should use this badge too in my opinion
in IKIcon.h :
IKBadgePositionFlagSemanticMask = 0x7FFF // Use this to mask out
the high bit. (Is this endian-safe?)
I think it is endian-safe.
+(id) iconForFile: (NSString*)path;
-initWithURL: would be welcome too.
// Icon needs to be scaled/moved before compositing?
if( pos.origin.x != 0 || pos.origin.y != 0
|| pos.size.width != mySize.width || pos.size.height !=
mySize.height
…
if( (pos & IKBadgePositionFlagTop) == IKBadgePositionFlagTop )
// Move to top?
box.origin.y += fullSize.height -box.size.height;
if( (pos & IKBadgePositionFlagRight) == IKBadgePositionFlagRight )
// Move to right?
box.origin.x += fullSize.width -box.size.width;
What is the reason of the question marks here ?
… otherwise everything looks ok for me from an architectural
perspective. We need to solve the compositor problem now and to do the
merge with the version in Étoilé cvs, and on my side to refactor
IKProvider related classes.
Would be nice too to merge our various demo examples in one example
compiling on both GNUstep and Mac OS X, and which demonstrates
compositing operations (with optional property list), badges and
providers mechanism (this last part of the demo would be invisible
under Mac OS X probably ).
Oh, and Nicolas, if you don't have the URL of the repository, contact
Quentin or me off-list. I just don't want it to end up in the list
archives because it's not really related to GNUstep or Etoile at all.
I have sent the url of the repository to Nicolas.
see you,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
