Re: generating bundles without an extension?
Re: generating bundles without an extension?
- Subject: Re: generating bundles without an extension?
- From: Rua Haszard Morris <email@hidden>
- Date: Wed, 14 Feb 2007 12:15:39 +1300
Basically I'm whining about an obscure (and maybe irrelevant) finder
inconsistency.. thanks for your help.... but
I'm using Xcode to generate plugins (Carbon bundles) for our app,
and up until now they've had the default extension ".bundle".
Ideally I'd like to have no extension,
Given that Mac OS X uses extensions almost everywhere, why do you
not want an extension? What about just hiding the extension?
Historically our plugins have no extension, and are identified by
file type (they're not code fragments anymore (!), but a bundle still
has a type and creator). We could introduce an extension, but I
wouldn't want to do this without fully evaluating the possibility of
no extension.
but there seem to be some problems related to this:
1. The finder starts showing the bundle as a folder if no
extension is used (doesn't seem to matter if the extension is
something random).
Packages/bundles are folders with names whose extensions are
registered with Launch Services as belonging to a package. Look at
the plist of an application that supports some kind of package
document such as TextEdit (.rtfd documents are packages).
LSTypeIsPackage is documented as describing whether the app is
packaged, http://developer.apple.com/documentation/Carbon/Conceptual/
LaunchServicesConcepts/.
I've just tried setting it to true for the appropriate OSType in the
launch services bit of our plist, to no avail.
For example, is there somewhere that documents the fact that a
bundle _must_ have an extension in order to be displayed correctly
in the finder?
Mac OS X is extension-oriented. Not using an extension would be
nonstandard and could confuse some users. FWIW, you can set the bit
to hide the extension.
Yet Launch Services still supports OSTypes. I have nothing against
extensions, and have not seen any documentation encouraging me not to
use OSType in isolation for this purpose.
http://developer.apple.com/documentation/CoreFoundation/Conceptual/
CFBundles/index.html mentions "known extensions" and "structure
type indicating a modern bundle" but nothing very concrete. My
guess is that if there is any extension, the finder looks at the
structure to determine if it's a bundle.
I discourage guessing as an approach to software development. As is
often the case when guessing, your guess here is wrong, and it's
easy to verify that by changing the extension of a bundle or
package, such as an application.
I'm surmising. Interestingly, when I tried what you suggested on an
app, (our app or another app) you're right. However when I try it on
a bundle, my surmising stands up better; a random folder, with the
contents of a real bundle (Contents/MacOS, PkgInfo, Info.plist...
etc) shows up as a folder, and if you give it any extension, it is
suddenly viewed as a bundle. So it isn't as clear cut as you may
think....
Interestingly the CFBundle apis and our plugin loading/management
code works correctly even when the finder doesn't show the plugin
as a bundle.
That's a different system.
It is related though?! The "what is a bundle" rules are consistent,
right?
Also I'm still interested to find out why not using an extension is
not supported in Xcode, or if there's a better way to pull it off
(than scripting after the build).
Thanks,
Rua HM.
_______________________________________________
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