FROM : John Stiles
DATE : Tue Oct 12 18:40:46 2004
On Oct 12, 2004, at 9:21 AM, Charles Srstka wrote:
>
> FSFindFolder works, but I have always wondered why Apple hasn't built
> in a Cocoa API for accessing these folders. Having to go through
> Carbon to do this is kind of annoying.
>
> Yes, there are third-party categories that give this functionality,
> but it really should be part of the default API.
I've never understood this attitude. I must be missing something,
because to me it feels elitist.
What's the difference between calling FSFindFolder and, say, [NSFolder
folder:kApplicationSupportFolder]? One isn't inherently better than the
other, and there's no reason to think that AppKit is the best way to do
EVERYthing. AppKit is really, really good at most stuff, so we get used
to relying on it, but they haven't managed to get every Mac-related
idiosyncrasy wedged in there yet, so there are still some pretty
glaring gaps (like this one, or types and creators, or aliases, etc
etc). And honestly I don't think Apple is providing much extra value if
they spend all their time writing each API twice, once with brackets
and once without :) Sure, FSRef isn't a super-common type to be passing
around in Cocoa code, but you're one call away from turning that into a
path, and you can easily encapsulate the entire conversion of
FSRef->NSString within a tiny helper function.
NSString *FindFolderNS( .... )
{
FSRef myRef;
if( noErr != FSFindFolder( ... ) ) return NULL; // or maybe @"" ??
UInt8 path[PATH_MAX];
if( noErr != FSRefMakePath( ... ) ) return NULL;
return [NSString stringWithUTF8String:path];
}
Come on, that wasn't a big deal :) So I don't understand the
complaining we see on this list any time we can't use AppKit to do
something...
DATE : Tue Oct 12 18:40:46 2004
On Oct 12, 2004, at 9:21 AM, Charles Srstka wrote:
>
> FSFindFolder works, but I have always wondered why Apple hasn't built
> in a Cocoa API for accessing these folders. Having to go through
> Carbon to do this is kind of annoying.
>
> Yes, there are third-party categories that give this functionality,
> but it really should be part of the default API.
I've never understood this attitude. I must be missing something,
because to me it feels elitist.
What's the difference between calling FSFindFolder and, say, [NSFolder
folder:kApplicationSupportFolder]? One isn't inherently better than the
other, and there's no reason to think that AppKit is the best way to do
EVERYthing. AppKit is really, really good at most stuff, so we get used
to relying on it, but they haven't managed to get every Mac-related
idiosyncrasy wedged in there yet, so there are still some pretty
glaring gaps (like this one, or types and creators, or aliases, etc
etc). And honestly I don't think Apple is providing much extra value if
they spend all their time writing each API twice, once with brackets
and once without :) Sure, FSRef isn't a super-common type to be passing
around in Cocoa code, but you're one call away from turning that into a
path, and you can easily encapsulate the entire conversion of
FSRef->NSString within a tiny helper function.
NSString *FindFolderNS( .... )
{
FSRef myRef;
if( noErr != FSFindFolder( ... ) ) return NULL; // or maybe @"" ??
UInt8 path[PATH_MAX];
if( noErr != FSRefMakePath( ... ) ) return NULL;
return [NSString stringWithUTF8String:path];
}
Come on, that wasn't a big deal :) So I don't understand the
complaining we see on this list any time we can't use AppKit to do
something...
| Related mails | Author | Date |
|---|---|---|
| Peter Karlsson | Oct 9, 16:38 | |
| Sherm Pendley | Oct 9, 17:34 | |
| David Reed | Oct 9, 17:57 | |
| Finlay Dobbie | Oct 9, 18:11 | |
| Steven Kramer | Oct 10, 22:38 | |
| Sean McBride | Oct 12, 02:40 | |
| Charles Srstka | Oct 12, 18:21 | |
| John Stiles | Oct 12, 18:40 | |
| stephane sudre | Oct 12, 19:04 | |
| John Stiles | Oct 12, 19:36 | |
| Rosyna | Oct 12, 20:43 | |
| Greg Hurrell | Oct 18, 01:31 | |
| John Stiles | Oct 18, 18:03 |






Cocoa mail archive

