At 15:31 Uhr +0100 03.01.2005, Quentin Mathé wrote:
I would prefer to have a method like
-setCompositor: because the compositor will be
set only once (when you start to use the
IconKit) normally, and the default compositor
may also depend on the target platform (Cocoa or
GNUstep).
If you mean +setCompositor:? I would be okay
with that. I don't really see why the compositor
should be an instance method in that case.
Now IKIcon.h related comments :
typedef NSString* IKIconIdentifier; //
Would be a struct containing type/creator on
Mac.
I don't think such typedef is really needed, in
such case Cocoa or GNUstep uses standard
NSString.
Actually, it is. In MacOS X, I would implement
this using Carbon under the hood, and I don't
think it's necessary to add the overhead of a
NSString-to-Carbon-type/creator translation
table. So I'm typedefing this so I can make it a
struct IKIconIdentifier { OSType type; OSType creator; }
on OS X. On GNUstep, you'd probably keep it as
the suggested NSString, which would probably just
contain the names of the image files you're using.
This icon identifiers should be moved to IKxxxProvider.h I think
Yes, they can go in their own files. However,
I'm thinking about maybe not having an
IKIconProvider class on OS X (since OS X already
has Carbon Icon Services to do the actual work).
Do you think we really need the additional
overhead of an IKIconProvider, or could I leave
that as an implementation detail?
I could also create icon providers on MacOS, but
they would only be compatibility classes that
call through to the Mac IKIcon class (and thus
Icon Services).
+(id) iconWithIdentifier: (IKIconIdentifier)identifier;
+(id) iconWithExtension: (NSString*)suffix mimeType: (NSString*)mime
attributes: (NSDictionary*)dict; /* any param may be NIL */
These two methods should rely on IKxxxProvider
classes for their implementation.
Yes, they'll probably rely on the corresponding init methods.
-(id) initWithIdentifier: (IKIconIdentifier)identifier;
-(id) initWithExtension: (NSString*)suffix mimeType: (NSString*)mime
attributes: (NSDictionary*)dict; /* any param may be NIL */
idem.
These two methods should rely on IKxxxProvider
classes for their implementation.
Yes, or on Icon Services and Launch Services on OS X.
A method - (id) initWithPropertyList:
(NSDictionary *)plist; needs to be added here.
With the IconKit, the compositing pipeline used
by the compositor can be loaded from a plist or
saved to a plist. The compositing pipeline is
represented and manipulated with
IKCompositorOperation, more precisely a
recursive chain of IKCompositorOperation.
Thanks for the explanation. I initially thought
that this dictionary stuff was your own
replacement for 'icns' files, and thus thought
I'd leave that out as it wouldn't be the same on
GNUstep and OS X.
// Compositing:
-(void) addIcon: (IKIcon*)src toRect: (NSRect)pos;
-(void) addIcon: (IKIcon*)src toRect: (NSRect)pos
operation:(NSCompositingOperation)op fraction:(float)delta;
We need few extras methods here to support
standard compositing position, take a look at
IKCompositorOperation.h :
typedef enum _IKCompositedImagePosition
{
IKCompositedImagePositionCenter,
IKCompositedImagePositionLeft,
IKCompositedImagePositionTopLeft,
IKCompositedImagePositionTop,
IKCompositedImagePositionTopRight,
IKCompositedImagePositionRight,
IKCompositedImagePositionBottomRight,
IKCompositedImagePositionBottom,
IKCompositedImagePositionBottomLeft,
} IKCompositedImagePosition;
No. Actually those are taken care of by the badgeRect etc. methods.
// 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 }
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?
// For theme-switching:
-(void) update; // Reloads the
icon, possibly from the new theme.
You prefer -update to -render method name ?
Update is different from render. You render
method returned an NSImage. update updates the
internal image used by the IKIcon (in the case of
OS X, it would actually update the IconRef).
-image is the method that actually gives you an
NSImage (lazily creating one on OS X as needed).
So yes, for what these two messages do in my
design, I prefer update/image to (NSImage*)render.
E.g. the GNUstep theme engine would call -update
on each icon currently alive whenever the theme
changes, causing the IKIcon to request its
current icon image again, getting an image that
fits the new theme.
-(NSImage*) baseImage; // The image of
the icon before any badges or compositing are
applied.
-(void) setBaseImage: (NSImage*)img;
I my opinion, theses methods are not needed
-initWithImage: and addIcon: blabla: are
sufficient for this task, moreover I think the
base shouldn't be fixed (in the future we could
want to switch the compositing order on the fly).
You're right, they aren't needed. I was thinking too complicated.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
