Re: How packages are recognized...
Re: How packages are recognized...
- Subject: Re: How packages are recognized...
- From: Rua Haszard Morris <email@hidden>
- Date: Wed, 8 Aug 2007 10:21:03 +1200
I have a suspicion that the bundle bit doesn't help if the bundle
doesn't have an extension too, by the way (tore my hair out playing
with this a while back), so you might as well have a UTI for the file
extension (or use an existing one if it applies).
I had set up a UTI for our package type without an extension, i.e. it
was based on type and creator (which are present in our bundles in
the plist and in a Pkginfo file) and the finder would not display the
package as a package unless there was an extension (it didn't matter
what it was.
Not sure if this info is of use to anyone but it seems relevant to
the discussion...
On 8/08/2007, at 6:21 AM, Alastair Houghton wrote:
On 7 Aug 2007, at 19:08, Mark Wagner wrote:
On 8/7/07, Alastair Houghton <email@hidden> wrote:
Perhaps the biggest advantage of UTIs over this kind of thing is
that
they aren't specific to HFS+. i.e. If you copy a bundle that has
its
bundle bit set to a disk that isn't using HFS+, it's possible that
you'll end up with a folder rather than a bundle (I haven't checked,
but it seems likely). The same wouldn't happen with UTI
declarations.
Perhaps the biggest advantage of the bundle bit over UTIs is that
they
don't depend on which applications you have installed. i.e. if you
copy a bundle of type .xcodeproj to a computer that doesn't have
Xcode
installed, it's likely that you'll end up with a folder rather than a
bundle. The same wouldn't happen if the bundle bit had been set.
:-D :-D
The obvious conclusion is to do both: declare the UTI as a bundle
type, and set the bundle bit. If there's some way of using a plist
file to indicate the containing folder is a bundle, you should do
that
as well.
Indeed.
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40adinstruments.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden