Le 9 févr. 05, à 10:14, M. Uli Kusterer a écrit :
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.
ok, I missed it by marking it wrongly as read. I will take a look at it.
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.
yep, the newsgroup is not really well supported.
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?
Well, current functionality with only NSImage.
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.
I have just seen you subversion repository update. I need to look at it.
That's really cool, I will try to take some times to merge theses
changes back in our cvs.
- #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.
Keep #include, may be we will switch to #import later if GNUstep people
are ok.
- 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.
Thanks.
- 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?
You should read :
http://cvs.gna.org/viewcvs/etoile/Etoile/Frameworks/IconKit/README?
rev=1.2&content-type=text/vnd.viewcvs-markup
Nicolas has written a demo application for this feature, he still has
it I think, but I don't know where I put it on my computer sadly, and I
never take the time to commit it the previous months…
This plist is to be used like a simple image format rules based with
possibility to reuse the composite rules. To take an example, we could
support possibility like wathever.ikicon bundle which would contain the
plist with the composite rules and a bunch of images stored into it,
then when you open it with IconKit the framework transparently returns
a NSImage you can use… you have also the possibility to create a new
IKIcon with the plist and change one and more images used by it as
specified in the plist… I haven't written this part of IconKit myself,
I hope Nicolas could confirm what I said and may be he has other ideas
too… The API could need to be polished a bit more.
Finally in some way it's like a very basic SVG format but with
GNUstep/Cocoa semantic and the bundle idea.
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.
ok…
Any special comments Nicolas ?
- @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).
ok, I will add #ifdef
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.
ok, I'm fine with this solution.
PS - I'd be willing to write an initial GNUstep version of IKIcon,
too, which you could then plug into your various providers.
If you are able some time to do, it would be nice.
Thanks,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
