Frameworks act like folders so that users can browse their header
files in Finder. As a developer, I think I would want that frameworks
be treated atomically for synchronization purposes.
My understanding is that Finder decides that frameworks are user
browsable because they're directories, but not packages. Applications
are not user browsable because they descend from com.apple.package.
The bundle type says something about how the directory's contents are
arranged; the package type says something about how it should be
presented to the user. You can have either, both, or neither.
Unfortunately I don't know the details of Spotlight or iDisk
synchronization with respect to these types.
On May 11, 2009, at 5:11 AM, Chris Idou wrote:
I'm surprised that frameworks act like folders in Finder, yet don't
conform to public.folder.
To be more explicit, I'm writing some code that synchronises two
folders. If directory A contains file X and directory B contains
file Y, then synchronising them depends on what kind of directory it
is. If it is a package, then a resulting package containing files X
and Y would be wrong, it could be a corrupt package. Folders should
be synchronised and have both X and Y. But I'm not sure about
frameworks being neither a folder nor a package. What would users
expect?
Hmm, I see that bundle, package and folder are the three decendents
of public.directory. framework conforms to bundle rather than
package and appears in the finder like a folder. However
applications descend from bundle and do NOT appear like folders.
Why does finder decide that frameworks appear like folders?
And which items does spotlight indexing delve into? Which items
would iDisk synchronise atomically?
From: Peter Ammon <[email protected]>
To: Chris Idou <[email protected]>
Cc: [email protected]
Sent: Monday, 11 May, 2009 4:02:17 PM
Subject: Re: Packages vs bundles vs folders etc
On May 10, 2009, at 10:43 PM, Chris Idou wrote:
>> Would it be fair to say that if a path is a directory, and if
the kMDItemContentType != public.folder then
NSWorkspace.isFilePackageAtPath would
>return YES?
>
>No. A non-package directory may not even conform to
public.folder. For example, volume mount points have the type ID
public.volume, which does
>conform; but frameworks have the type ID public.framework, which
does not conform.
But isn't a framework a package, thus making my statement correct?
If a framework is not a package, then what specifically makes a
package a package that a framework doesn't fit?
Frameworks are not packages. A package is a directory that is
presented as a single file to the user, but frameworks are shown as
folders and are browsable like other folders.
You can check the UTI hierarchy in the UTCoreTypes.h header (try
open -h UTCoreTypes.h).
Perhaps I should state my question more explicitly. I'm trying to
figure out what things should be copied atomically. When a
directory is really a bundle (is a bundle == package?), then it
must be considered as one unit. If it's just a folder, then the
files therein have their own unique reasons for existing. But I'm
not sure which API exactly will give me the distinction I want to
make.
If you copy two folders, Finder reports the total number of items
contained within them; but if you copy two applications, Finder
reports only two items. Is that the sort of distinction you want to
make?
If so, I think you're on the right track. On Leopard, I would get
the UTI of a file via -[NSWorkspace typeOfFile: error:], and then
see if it conforms to kUTTypeFolder via -[NSWorkspace type:fileType
conformsToType:(NSString *)kUTTypeFolder]. If it does NOT conform,
it should be treated as a single item.
If you need Tiger compatibility, you can do the same thing, except
you would use LaunchServices functions like LSCopyItemAttribute().
-Peter
Chat right from the comfort of your inbox. Show me how..
_______________________________________________
Cocoa-dev mailing list ([email protected])
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
