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.
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.
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'm just trying to save myself some work here
for the OS X port. If IKIcon already provides
an API for everything needed, I'd prefer if
IKIconProvider just stayed a secret GNUstep
implementation detail, just like Carbon Icon
Services are a secret MacOS implementation
detail. But if there's a real need for an icon
provider class for some other reason, I could
be convinced to write one for OS X, too.
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?
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.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
