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: Fri, 6 Feb 2004 11:05:02 -0600
- Thread-topic: Are we still supposed to register Creator code (bundle signature) for OS X app?
>
I was talking about Apple's creator and type code registry, which is
>
the place where you must register any creator codes that your app
>
owns.
>
>
Ah! Now I understand your question: I thought by "register" you
>
meant "register it with Apple via the type and creator code
>
registry". But you were referring to typing a creator code into the
>
"properties" pane of your application, right?
Actually, in my mind, one follows the other. If I am going to register
the code with Apple, it would be silly not to then specify it in the
properties for the application. But the core issue is to whether or
not a creator is still a requirement for an OS X only app.
I guess my question is answered by "it depends". I was wondering if
anything had come from Apple beyond TN2034 (shudder) that I had not
come across.
As I stated, my specific app that raised this issue for me really has
no need for one, its just a utility that looks at other files rather
than being a primary viewer/editor for any particular file type.
I guess I will just register/specify one and ignore it any further
then that.
Guy
-----Original Message-----
From: M. Uli Kusterer [
mailto:email@hidden]
Sent: Friday, February 06, 2004 10:33 AM
To: Guy Umbright; email@hidden
Subject: RE: Are we still supposed to register Creator code (bundle
signature) for OS X app?
At 22:24 Uhr -0600 05.02.2004, Guy Umbright wrote:
>
Should an OS X app still register a Creator code?
If you are using a creator code, you should register it, yes.
>
I have an app that really has zero use for one.
Then don't enter a creator code on the properties pane. If you don't
enter one, you're not using it, and thus you don't need to register
it.
>
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.
The creator code really doesn't have much to do with making it the
default these days. It simply indicates what application
>
(And how is the creator code well hidden? Its on the same property
page
>
as the identifier?)
I was talking about Apple's creator and type code registry, which is
the place where you must register any creator codes that your app
owns.
Ah! Now I understand your question: I thought by "register" you
meant "register it with Apple via the type and creator code
registry". But you were referring to typing a creator code into the
"properties" pane of your application, right?
Well, there hasn't been official word from Apple on that. Well,
there has, but it was part of the infamous tech note 2034, which was
pulled a few days after its release. It's come up on the list a
couple times since then. If you search the archives of this list
you'll probably find one of the discussions. I'll try to summarize it
here quickly, but note that I'm in the pro-creator/file type camp,
which means I probably only remember what I want to:
1) Type and creator aren't strictly needed on MacOS X anymore. The OS
now uses the bundle identifier to tell apart applications. However,
types and creators aren't ignored either.
2) However, the user can re-assign file --> application mappings on a
per-creator basis in the Finder ("Change all"). Which gives finer
granularity than if it's done solely per-extension (which is what
happens for files without a creator). Some users see that as an
advantage (I can make all text files created with Guy's app in
CodeWarrior, while text files downloaded from the net will open in
OpenOffice), others see it as a disadvantage (I have to "change all"
for each creator, and can't just override it for all ".txt" files).
Since people have fewer apps than files usually, I think the former
is more powerful, and the latter isn't that much of a hassle.
3) MacOS 9 applications don't cope too well with files that don't
have a type and creator. If it's likely that your users will use
Classic apps to work on the files your app generates, chances are
you'll want to help them by assigning a type and creator to your app,
and to the files it creates. I posted a small NSDocument subclass
(UKDocument) that takes care of this transparently. I can put it up
on my web site if there's interest.
4) If you have a utility, it's also pretty common practice to let the
user enter a creator that will be set for the files (for text files
the type would just be "TEXT"), so they can pick an app to open it in.
Hope this info helped you a bit.
--
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.