At 2:53 Uhr +0100 09.02.2005, Quentin Mathé wrote:
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 ?
2005-01-07 @ 17:43 and 18:08 (CET) Re: [Etoile-dev] IconKit redesign
I was asking about NSCompositingOperation in
one, and the other one was my arguing against the
class cluster approach for Icon Providers, using
NSString as an example.
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 ?).
I'm reading the newsgroup, and actually I'm even
posting to that ... but I suspect that NG
messages are no longer being forwarded to the
mailing list... I'll have to go hunting for the
mailing list URL.
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 ;-).
Current functionality plus variants for getting
IKIcon objects, or current functionality with
only NSImages?
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.
I've finished the test app and reorganized the
sources some more. I've also compiled it, fixed a
few typos and it works nicely now, even with
basic compositing. You should find a copy in my
SVN when it goes back up again.
- #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).
It's only a search-and-replace. So, pick one and I'll use that.
- 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).
I'll do it. It's close to my coding style, so I
hope it won't annoy me too much.
- 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.
I haven't implemented the property list stuff
(yes dictionaryRepresentation is for that)
because I don't really know what should go in
there and how. Should this simply be a list of
standard icon names and the rects into which they
will be composited? What if it gets an IKIcon
that isn't a standard icon? Save the icon image
as NSData to the plist?
Can you tell me what this property list thing
will actually be used for? I.e. explain what
people will use this for in real life, and what
data will be saved and what won't?
I didn't choose -propertyList because on
NSString that's a method that parses the string
and creates a plist based on that. So I picked
the name from NSUserDefaults, which I think is
more like what this will be doing, because it
collects the info from the object and generates a
plist from that.
- @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.
Since this code will need to be completely
rewritten for GNUstep anyway, I'd rather just
leave it this way, if you don't mind. I may
change this if I find myself writing any code
that would be more portable, though (like when I
add support for compositing operations and
transparency).
BTW -- I'm still not sure how we'd best handle
one aspect of badges: On MacOS X, most standard
badges the OS provides are actually full-size
icons of which only a small area is used. I.e.
the "symlink" arrow icon is actually a full-size
icon with a small arrow in the lower left.
Obviously, you can't composite that into a small
rect in the lower left, because it'd become tiny.
OTOH, when you composite a full-size application
icon onto another icon, you need to scale it
down, obviously. Would you mind if I added two
constants for positioning badges? One for placing
other icons into the symlink-position (e.g. if
your app wants to display a red arrow for soft
links and a blue one for hard links, it'd just
draw those full-size and composite them scaled),
and another one solely for use with the standard
symlink icon?
On Mac, the latter would simply map to
full-size, while the former would stay the way it
is now.
PS - I'd be willing to write an initial GNUstep
version of IKIcon, too, which you could then plug
into your various providers.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
