Le 11 mai 09 à 23:06, Alastair Houghton a écrit :
On 11 May 2009, at 19:08, Sean McBride s...@rogue-research.com
wrote:
On 5/11/09 1:55 PM, Alastair Houghton said:
I'm not sure whether this is now classed as legacy behaviour, but on
HFS+ at least, Finder looks at the bundle bit to
On 12 May 2009, at 08:23, Jean-Daniel Dupas wrote:
Le 11 mai 09 à 23:06, Alastair Houghton a écrit :
I should explain what I meant a bit better. My point was more that
the bundle bit is HFS specific, so like the type and creator codes,
while it's good to set it, I'm not sure anything
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
?
And which items does spotlight indexing delve into? Which items would iDisk
synchronise atomically?
From: Peter Ammon pam...@apple.com
To: Chris Idou idou...@yahoo.com
Cc: cocoa-dev@lists.apple.com
Sent: Monday, 11 May, 2009 4:02:17 PM
Subject: Re: Packages vs bundles
pam...@apple.com
To: Chris Idou idou...@yahoo.com
Cc: cocoa-dev@lists.apple.com
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
On 11 May 2009, at 13:42, Peter Ammon wrote:
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
On 5/11/09 1:55 PM, Alastair Houghton said:
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
On May 11, 2009, at 11:08 AM, Sean McBride wrote:
Are you sure the Finder consults the bundle bit? I would think that
it's Launch Services doing that.
Yes, it does:
mkdir -p /tmp/foo/bar/bat
SetFile -a B /tmp/foo
open /tmp
Note that finder thinks foo is a single item, not a folder.
On 5/11/09 11:47 AM, Dave Carrigan said:
Are you sure the Finder consults the bundle bit? I would think that
it's Launch Services doing that.
Yes, it does:
mkdir -p /tmp/foo/bar/bat
SetFile -a B /tmp/foo
open /tmp
Note that finder thinks foo is a single item, not a folder.
If you do
On 11 May 2009, at 19:08, Sean McBride s...@rogue-research.com
wrote:
On 5/11/09 1:55 PM, Alastair Houghton said:
I'm not sure whether this is now classed as legacy behaviour, but on
HFS+ at least, Finder looks at the bundle bit to determine whether
something is treated as a bundle or just
Also, I don't think the bundle bit is 'legacy'.
I should explain what I meant a bit better. My point was more that
the bundle bit is HFS specific, so like the type and creator codes,
while it's good to set it, I'm not sure anything should be relying
on it.
The main reason for setting
On May 11, 2009, at 1:02 AM, Peter Ammon wrote:
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
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? And conversely if a path is not a directory or the
kMDItemContentType == public.folder, then NSWorkspace.isFilePackageAtPath would
On May 10, 2009, at 6:46 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
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
15 matches
Mail list logo
