Le 4 janv. 05, à 21:36, M. Uli Kusterer a écrit :
At 20:54 Uhr +0100 04.01.2005, Quentin Mathé wrote:
I know. I haven't written I don't want Carbon code in IconKit, I just
want the Carbon code to be put in separated classes when possible.
I'd put them in separate source code files at most (as categories),
but I don't think separate classes are necessary. That'd only add more
runtime overhead, and make it harder to find things. Since the
internal implementations are so different, I'd actually prefer if we
just designed the API together, and then each platform gets their own
copy of the header, with slight additions as needed by the platform.
That's probably simpler to do it like that… but the runtime overhead is
not real, to take a simple example the NSString which is probably one
of the most performance critical class is based on the class cluster
pattern. Moreover, I don't understand why it would be harder to find
things with a file called IKIconCarbon.m than with a file called
IKIcon+Carbon.m (the file for the category). If you put the Carbon
category in the IKIcon.m file I would personally say the result is less
clear by being less cleanly separated.
Are there any features IKIconProvider offers that *users* of the
code may want to access?
No, except IKApplicationIconProvider because it has no equivalent on
Mac OS X. And GNUstep applications which relies on this functionality
would need it when ported to Cocoa.
What does IKApplicationIconProvider do that can't be done using
IKIcon right now? IKIcon already gives you the standard application,
document and plugin icons. You can composite your app's icon on the
other two to get document icons. Do we need more? Okay, it can get an
icon for an application specified using its bundle identifier, but I'd
just say find that application's path using its bundle identifier
first, and then get an icon for the item at that path.
Exactly, but I would like to avoid to put everything in IKIcon…
Especially because IKApplicationIconProvider needs a cache system to
avoid to the application the need to recreate IKIcon instances when
they have been deallocated, this cache system is bundle identifier
based and not file names based then it is a different beast than
IKIconProvider cache system and moreover they have different uses.
Well, however as I accept it below IKIconProvider is not really needed
on Mac OS X… And IKApplicationIconProvider cache system might be
replaced by Icon services cache perhaps ?
We'd want a category on NSWorkspace to find an application's path
based on its identifier, but that's not tied to icons at all, because
people looking for a particular app can also use that method.
IKIconProvider would probably just do a check and if a folder is an
application package it would drill into the package to fetch the right
icon.
I already thought of that, but I haven't take the time to write a
NSWorkspace category currently and more importantly to add support for
bundle identifiers in the make_services tool which is doing the job of
Launch services on GNUstep.
I don't understand why the choice to put the Carbon code in a
separate class which can be called with a semantic identical to
GNUstep related IKIconProvider would more complicated than put this
Carbon code in IKIcon directlyŠ ?
There are no IconRefs on GNUstep. So any transfer of image data
between IKIcon and IKIconProvider (if they are classes applications
can use) will have to happen using NSImage or other OpenStep data
types. Now, on GNUstep that's okay, but on MacOS, this would mean that
IKIconProvider would ask the OS for an IconRef, convert that to an
NSImage, and then IKIcon would have to work with that. Which would be
ineffective in most cases on MacOS, because it'd just be an
unnecessary copy.
So, I'd want IKIcon to use IconRefs internally. But if it does that,
IKIconProvider is simply a middle-man who asks Icon Services for the
IconRef, and then hands it to IKIcon. It would simply do "stupid
forwarding". Why not make the icon Services on MacOS in IKIcon right
away, and save cycles?
ok, I understand now.
It's completely sensible to have IKIconProviders on GNUstep OTOH,
since it doesn't have Icon Services. So, IKIconProvider would be a
class that fetches standard images and loads GNUstep icons from files
(whatever format you choose for storing them), and IKIcon would use
these to request NSImages to keep in its icons.
Does that sound sensible? I must say I'm not quite sure whether I'm
now complicating the GNUstep side of things and I'm just not noticing
it.
hmm, no you are not complicating the GNUstep side of the things ;-)…
but it's true that I haven't a clear vision on my side on how to
integrate the already existing cache system of Icon services with the
one implemented by IconKit without overlapping behaviors.
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
