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.
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.
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.
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.
Are there any features IKIconProvider offers
that *users* of the code may want to access? 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 have an IconKit test application which
demonstrate this stuff, I will send it to you, I
need to clean a bit before to put it in the cvs
developer examples part.
Okay. A notification once it's done is - as always - appreciated.
// Standard rects to use:
-(NSRect) badgeRect;
-(NSRect) subIconRect; // Anybody have a better name?
Theses methods should be class methods.
No. They change depending on the icon size.
I.e. if the badge is in the lower right and
usually a quarter of the size of the full icon,
and you create an icon using initWithSize: for
256 x 256, -badgeRect would return { {128,0},
128,128 }
ok. I haven't thought of that.
I must say I'm not sure to understand what is
the precise use of -subIconRect and how it would
work ?
I remembered you want to allow auto-generating
document and plugin icons by e.g. drawing a small
MyCoolApplication icon onto an empty document
icon, to create a standard
MyCoolApplication-document icon. subIconRect
would in this case give the rectangle where you
want the MyCoolApplication icon to be drawn.
-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.
Though this still doesn't solve the problem of
MacOS X badges fully: On OS X, badges are
usually icons that are simply transparent in
three quarters. So, they'd have to be
composited onto another icon at full size. I
agree that we need to be able to specify custom
rects to use when badging full-size icons onto
others (e.g. to have a "caution" icon badged
with the current app's icon), but we may also
want to have a way for an icon to tell its
owner "my used rect is xy..." Maybe just having
a usedRect method might solve that?
Would be ok I think.
I would like to have a -subIconRectForPosition:
method which would take in parameter
IKCompositedImagePosition enumeration value (we
should probably rename it IKCompositePosition or
IKCompositedIconPosition or IKSubIconPosition
?) IKCompositedImagePosition is here to encode
badge rects variations like 'top left badgeRect'
'center badgeRect', then the -badgeRect returned
value would be the 'canonical badgeRect' aka
'bottom right badgeRect'
(IKCompositedImagePositionBottomRigh).
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?
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
