Le 8 févr. 05, à 15:20, M. Uli Kusterer a écrit :
Quentin,
Hi Uli,
you didn't really write anything in response to my last two postings,
so I thought I'd just sit down and do a first "testing" implementation
of IKIcon for Mac to see whether there are any holes in this.
hmm, I'm sorry, but which two postings are you talking about because it
seems I haven't received them… have you sent them to my mail address or
to this list and when ?
I've attached a copy.
One thing I've realized is that, design-wise, you may actually have
been right that we'll want to move more out of IKIcon. While IKIcon
itself will definitely house most of the functionality on MacOS X,
API-wise it just doesn't look clean.
ok. We will see what we can do to fix this problem.
In particular, when you see that NSWorkspace has iconForFileType: and
iconForFile methods, it seems kind of counter-intuitive to have users
go to IKIcon to get an icon for a particular MIME type. I've started a
category on NSWorkspace (in IKIcon.h, for now) that returns IKIcon
objects, and I'll probably extend that to offer MIME type lookup for
icons as well.
Like you, I planned initially to add a category to NSWorkspace to do
that, the category would be loaded by a -gui bundle in order GNUstep
applications use the IconKit even without knowing it is installed or
not, I talked about that on GNUstep -discuss list today (you are still
reading it may be ?).
But I think it'll become kind of crammed if we also add a method for
"icon by identifier" into NSWorkspace. What do you say?
yep probably, I think we should probably just support the current
functionality of Workspace (but not more) with the category.
NSWorkspace is a bit a "bastard class" I think, which would may be
disappear if OpenStep was redesigned from scratch today ;-).
Let me know what you think of this first IconKit implementation. Note
that I haven't compiled it yet, I'll get to writing a test app for it
next.
The implementation looks pretty good.
Few remarks however :
- #include are not needed over #import with new GCC versions, but may
be it is good to keep them when you take in account the goal is to have
IconKit included in GNUstep cvs itself (which is still often compiler
whit old GCC versions).
- I'm sorry but, you or I will need to modify the current formatting to
match the GNUstep coding standards when we will move it to the GNUstep
cvs
(http://www.gnustep.org/resources/documentation/Developer/
CodingStandards/coding-standards_toc.html).
- A -initWithPropertyList: needs to be added.
- If -dictionaryRepresentation returns the property list, we should use
-propertyList for -dictionaryRepresentation, it seems more in
accordance with Cocoa/GNUstep semantic no ? But if
-dictionaryRepresentation is equivalent to -attributes then it should
be named with this last identifier.
- @synchronized is not supported by FSF GCC currently, then it should
be rewritten with NSRecursiveLock or NSLock
I would like to a have the code related to the custom Mac OS X cache
moved to separate file for the category or put in another object.
Thanks for you great work Uli,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
