Le 4 janv. 05, à 14:43, M. Uli Kusterer a écrit :
At 12:07 Uhr +0100 04.01.2005, Quentin Mathé wrote:
okŠ but when you said "keep it as the suggested NSString", you mean
the typedef would be discarded when IconKit would be compiled on
GNUstep and/or the methods which include IKIconIdentifier in their
signature (on Mac OS X) would use NSString in their signature for the
installed headers ?
No, we'd still be using IKIconIdentifier. Otherwise we couldn't have
full source code compatibility. I could make the MacOS X version a
class instead of a struct, though. That way people could stuff it in
an array, etc.
Well I think the typedef is ok now, no need to introduce a custom class.
I would really prefer to avoid too much carbon code in IKIcon
The Carbon code would be behind the scenes, but there is no getting
around it. Carbon is the only way to get at icons on OS X with the
flexibility and speed needed for Icon Kit.
I know. I haven't written I don't want Carbon code in IconKit, I just
want the Carbon code to be put in separated classes when possible.
and to rely on #ifdef __GNUstep__ tricks when we have the possibility
to hide the implementation variations more cleanly in separate
classesŠ but well I agree we should then redefine a bit IKxxxProvider
related classes.
May be :
IKIconProvider <-- class cluster
IKIconServicesProvider <-- for Mac OS X
IKIconKitProvider <-- for GNUstep
This last class IKIconKitProvider would be the 'cvs current
IKIconProvider' and uses the written classes
IKApplicationIconProvider and IKTumbnailProvider I think. Theses two
last classes should probably be renamed and/or may be the best
solution is to use a protocol IKProvider.
When you compile the IconKit on Mac OS X, you can have only
IKIconProvider and IKIconServicesProvider compiled, and no headers
installed (or may be IKIconProvider.h)Š on GNUstep it would be
different, for sureŠ
?
What do you think ?
I'm not sure I understand you here. A class cluster really only would
make sense if you wanted to provide different subclasses of the same
superclass at *runtime*, but in the case of IKIconProvider, the
decision which provider(s) you get is already made at compile-time,
and you always get the same object on the same platform. A class
cluster is the wrong Design Pattern to use here, IMHO.
ok… IKProvider protocol is probably the solution.
initWithIdentifier: and initWithExtension:mimeType:attributes:
already let people do everything they may need to get an icon. So,
although on GNUstep the icon images would actually be provided by
IKIconProvider, I'm tempted to just make that a private helper class
of IKIcon, and do without a IKIconProvider on MacOS.
A private helper can be a class which implements IKProvider protocol I
think.
Are there any features IKIconProvider offers that *users* of the code
may want to access?
No, except IKApplicationIconProvider because it has no equivalent on
Mac OS X. And GNUstep applications which relies on this functionality
would need it when ported to Cocoa.
I'm just trying to save myself some work here for the OS X port. If
IKIcon already provides an API for everything needed, I'd prefer if
IKIconProvider just stayed a secret GNUstep implementation detail,
just like Carbon Icon Services are a secret MacOS implementation
detail. But if there's a real need for an icon provider class for some
other reason, I could be convinced to write one for OS X, too.
I don't understand why the choice to put the Carbon code in a separate
class which can be called with a semantic identical to GNUstep related
IKIconProvider would more complicated than put this Carbon code in
IKIcon directly… ?
-compositeRect: or -compositedIconRect: is may be better than
-subIconRect ?
compositeRect doesn't say enough, IMHO. compositedIconRect sounds
like it was the rect *after* compositing, not to use *for*
compositing.
may be -targetRect: or -compositingRect… ?
Hmmm... good idea. What about this: We have one method:
-(NSRect) badgeRectForPosition: (IKBadgePosition)pos;
for returning all rects. There would be IKBadgePositionTopLeft,
IKBadgePositionBotRight etc. for when you really want the physical
position. OTOH, there would also be constants like IKBadgePositionLink
(which would be IKBadgePositionBottomLeft on MacOS, for the "symlink
arrow") and IKBadgePositionPermissions (= IKBadgePositionBottomRight)
for the "no way" icon you get when viewing a folder you don't have
permissions for etc.?
That way, GNUstep users could eventually configure where they want
these icons to be displayed, while on MacOS this constant could easily
be changed, should Apple decide they want the badges in a different
place all of a sudden.
Sound acceptable?
That's perfect.
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
