At 23:22 Uhr +0100 06.01.2005, Quentin Mathé wrote:
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.
The difference is that in NSString, the decision
which class to use happens at runtime. If there
are no other classes in the cluster on a given
platform, it's basically an "unclean" use of the
"Class Cluster" pattern.
Take NSString: When you use
initWithContentsOfFile: to create an NSString
object based on a file's contents, depending on
the size and the characters used in the file, you
will get a different NSString subclass. One does
lots of caching and is good for large strings,
while another use UTF8 internally instead of
UTF32, and thus saves lots of RAM for European
text, but Chinese text would become noticeably
larger.
So, depending on runtime input, you get
different classes from the cluster. There's a
slight overhead when a "pure NSString" object is
created in init and then disposed and the
subclass returned instead, but there's also a
benefit in that the OS can choose which subclass
to use to make your code as efficient as possible.
In our case, IKIcon.X wouldn't even compile
outside MacOS X. So at least on GNUstep, there
would only be IKIconProvider.GS. In addition, the
main class of the cluster would have to be
hard-coded to return IKIcon.GS on GNUstep and
IKIcon.X on OS X. It's not sensible to return an
object from another class on either OS. If there
was, we wouldn't even have a MacOS X or
GNUstep-specific implementation.
But if you always only get the same subclass,
then the overhead of the class cluster (creating
and tearing down one object of the cluster class
just to call "init" on it before creating an
object of the subclass instead) doesn't have a
benefit anymore.
And since e.g. Filie will get lots of icons when
listing a big folder, I'd rather avoid that
overhead where possible.
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.
I'd think that *any* IKIcon should be part of
this cache system. Not just the application
icons. If I request icons for three JPEG files,
it'd be much more efficient if I got the same
IKIcon instance each time. So I'm personally
tempted to put the cache in IKIcon right away.
The providers would only be used to load fresh
icons, so to say (on GNUstep), and from then on
the developer would get whatever cached icon is
appropriate.
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 ?
I actually have a secondary cache in UKFileIcon
for the ObjC objects, but yeah, internally it
would use Icon Services' cache to prevent having
to re-load the icons.
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 think I understand? Is there some reason
why this category is more work on GNUstep to
implement than having a scheme to look up icons
based on bundle identifiers in IconKit? The work
to be done would be the same, I guess, wouldn't
it? Find the bundle path based on the identifier.
Once that's done, loading the icon file is a
plist away :-) The difference would merely be
that the code is in a separate file.
If there's an easier way to do this for IconKit on GNUstep, do let me know!
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.
As I said, if this requires significant changes
or performance tradeoffs for GNUstep, tell me
what they are and I'll try to come up with a
compromise. Obviously you know the GNUstep side
of things better than I do. I'm basically
steering you toward the easiest implementation
for OS X right now, which is basically what I
already did for UKFileIcon (minus the compositing
stuff).
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
