Re: generating bundles without an extension?
Re: generating bundles without an extension?
- Subject: Re: generating bundles without an extension?
- From: Laurence Harris <email@hidden>
- Date: Tue, 13 Feb 2007 23:36:55 -0500
On Feb 13, 2007, at 6:15 PM, Rua Haszard Morris wrote:
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,
That was then. This is now. Lots of things have extensions now that
didn't have them back then. Don't get me wrong, I hate the greater
use of extensions. They look kludgy and hark back to a technology
that was inferior to types and creators. But Apple decided that
compatibility with other platforms was worth the change, and Mac OS X
is based on UNIX at the core with a smidgen of NeXT thrown in, and
neither supports types and creators, so there's a lot more reliance
on extensions now.
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.
Why does it matter? Mac OS X users are accustomed to extensions all
over the place. Lots of Mac OS X applications don't even support
types and creators anymore on their files.
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.
You'll need to use an extension you define for that to work.
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.
Understood, but that isn't the same as saying that you won't
encounter any issues if you don't use an extension. You may and you
may not, but I doubt Apple is investing a lot of resources to ensure
that bundles without extensions work without issues.
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?
Yes, but you're talking about two distinct technologies: Launch
Services and CFBundle, and they can use different rules even though
within each technology the rules are consistent.
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).
Xcode descended from ProjectBuilder, which had its roots in NeXTStep,
and the NeXT didn't have file types. Welcome to the future, which at
times looks remarkable like the distant past. ;-)
Larry
_______________________________________________
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