RE: Are we still supposed to register Creator code (bundle signature) for OS X app?
RE: Are we still supposed to register Creator code (bundle signature) for OS X app?
- Subject: RE: Are we still supposed to register Creator code (bundle signature) for OS X app?
- From: "Guy Umbright" <email@hidden>
- Date: Thu, 5 Feb 2004 22:24:43 -0600
- Thread-topic: Are we still supposed to register Creator code (bundle signature) for OS X app?
Thanks for the answer, but I am afraid I must have not been clear.
I know how to generate the bundle identifier, etc. What I wanted to know is
what is the official word from Apple?
Should an OS X app still register a Creator code?
I have an app that really has zero use for one. It open text files and saves
text files and I cannot imagine a case where you would want the app to be
the default for opening a type of file.
(And how is the creator code well hidden? Its on the same property page
as the identifier?)
Guy
-----Original Message-----
From: M. Uli Kusterer [
mailto:email@hidden]
Sent: Thu 2/5/2004 6:26 PM
To: Guy Umbright; email@hidden
Cc:
Subject: Re: Are we still supposed to register Creator code (bundle
signature) for OS X app?
At 15:34 Uhr -0600 05.02.2004, Guy Umbright wrote:
>
Please excuse the potential doofusry of the question, but are we
>
still supposed to register a creator code (now called a bundle
>
signature)
>
with Apple? The registration page doesn't really
>
mention OS X.
Creator/Signature code != Bundle identifier
If you're using a creator code, you still have to register a
signature on the (now well-hidden) cfType registry page. They are
still used actively by many applications (especially Carbon) and
still understood by the system, which means you can cause conflicts
if you pick a creator that is used by another app already.
>
As I understand it the bundle signature is still used for finding
>
the app a file type is to be opened with (set in file info or
>
otherwise).
Yes.
Bundle identifiers don't have to be registered as far as I know.
This is probably due to the fact that they are much less likely to
collide, as they are longer and include more unique segments of
information. The typical buldle identifier is of the form:
com|org.companyname|authorname.programname
( | designates alternatives) So, whenever you define a bundle
identifier for an app, anybody who causes a collision would need toat
least
a) be a Cocoa programmer
b) have the same name as you, or work at the same company
c) be working on a program with the same name as yours
So, even if there was another Guy Umbright that is a Cocoa
programmer, I think you'd have noticed if he was working on a program
with the same name as yours. And if he does a for-profit app and you
do an open-source one, chances are your bundle identifiers still
won't clash.
And if there's another developer working on a program with the same
name as yours, at the same company, then your company's too big, and
marketing will have your head. And if it's another company than yours
that just happens to have the name, were in the same situation as
above.
Of course, my word on this is as good as yours, but I've stated in
the past when people asked whether they should support type/creator
codes, that I think the benefit this gives your users is more
important than the little amount of work it saves.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
This electronic mail message and any attached files contain information
intended for the exclusive use of the individual or entity to whom it is
addressed and may contain information that is proprietary, privileged,
confidential and/or exempt from disclosure under applicable law. If you are
not the intended recipient, you are hereby notified that any viewing, copying,
disclosure or distribution of this information may be subject to legal
restriction or sanction. Please notify the sender, by electronic mail or
telephone, of any unintended recipients and delete the original message
without making any copies.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.