Le 3 janv. 05, à 20:37, M. Uli Kusterer a écrit :
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.
yes +setCompositor: :-)
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.
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 ?
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 would really prefer to avoid too much carbon code in IKIcon 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 ?
+(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.
Off course.
-(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.
ok, see my proposal above.
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.
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.
// 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.
No really in my opinion if I understand your proposal correctly… but
take a look below…
// 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 … ?
-compositeRect: or -compositedIconRect: is may be better than
-subIconRect ?
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).
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.
ok
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
