Totally agreed that seeing extensions on file names is unfortunate.
But as long as applications are properly setting/using the hidden
extension bit (and many do), most of the time users should not see
extensions on any of their files, except the ones where they want to
(for instance, developers usually like to see extensions on their
source files).
As someone else also pointed out, file extensions replace and augment
type codes, not creator codes. Creator codes are often used to cause
documents to open in a particular app. But having an app explicitly
and automatically mark documents it saves as opening in itself can get
frustrating for the user. Clearly for documents specific to a single
app, there is no issue; the document will automatically open in that
app thanks to its type (declared via file extension and/or type
code). For documents that are recognized by multiple apps, the user
has the power to bind a particular document to any app they wish,
using the file inspector in Finder. So at least for this purpose the
creator code is not needed.
Ali
On Apr 1, 2008, at 7:00 PM, Dave Sopchak wrote:
Ah, a subject near and dear to my heart.
I agree with Rainer, UTIs can be deduced from file types, extensions
and file creators, but I would sure like it if one could set a UTI
for a document and have this take care of things, not the other way
around.
Also, it certainly seems that UTIs do not do anything to function as
creator codes. Maybe we need a Universal Creator Identifier as well ;)
I love Cocoa, but I absolutely hate file extensions. Sure, they're
nice for compatibility with those "other" operating systems, but I
get tired of
.jpg
.xcodeproj
.iMovieProject
.extensionskeepgettinglongerandlonger
I tried looking around both Carbon (where UTIs seemed to be embraced
first for files) and Cocoa, and cannot find a reasonable way to set
a file's UTI and forgetaboutit, so that it's recognized by the
system as belonging to a specific application, without putting in an
extension or type/creator code. UTIs are clearly an improvement over
32 bit type codes, but what do I have to do? Would the UTI be
associated with the file's metadata? I think maybe, but in this case
I would expect a specific way for the system to look for this and
cannot find documentation to this end. It seems silly to have UTIs
and have them serve in what seems to me a superfluous manner.
Any advice would be welcome.
I would love (LOVE!) Apple to allow me a way to use UTIs as an
effective way to make file extensions optional, like in the good old
days.
Thanks for any and all. Apologies for the rant.
Dave
On Apr 1, 2008, at 4:44 PM, Rainer Brockerhoff wrote:
At 15:21 -0700 01/04/08, [EMAIL PROTECTED] wrote:
From: Andrew Farmer <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
Date: Tue, 1 Apr 2008 13:26:58 -0700
Message-ID: <[EMAIL PROTECTED]>
On 01 Apr 08, at 12:59, Marc Respass wrote:
I haven't registered for a creator code since System 7.5. Apple
has information and registration page (http://developer.apple.com/datatype/index.html
) about it but no indication if it's actually still required. Can
anyone tell me if it is still required or maybe point me at the
right information?
Type and creator codes have been deprecated since Tiger, which
introduced UTIs. (Maybe even longer; I'm not sure.) Either way,
you can safely forget they ever existed.
Type and Creator codes are alive and well in 10.5.x, and I haven't
seen any mention that they're deprecated.
They're still used by LaunchServices to bind documents to
applications. UTIs haven't substituted them, mostly because there's
no field in HFS+ that directly defines a UTI for a specific file;
instead the UTI is deduced from type, creator and extension
(perhaps also from file contents in some cases).
What actually happens is that file type is checked first, then file
extension, then file creator. LaunchServices matches them, in that
order, to registered applications. The same metadata are also used
to produce UTIs for that file, which are also used for matching.
It's still useful to register a creator code for your application
if you have documents/files that have no extensions (in that case,
also use a type), or that have some otherwise common extension, but
still need to show your app's document icon. All-lowercase code are
reserved.
There used to be some problems with using codes that contained
MacRoman characters with the high bit set - the codes use MacRoman
but the PkgInfo files (which are mostly obsolete these days) used
UTF8. I suppose that should work now, although I haven't checked.
Registering a code is much faster now - you get a response within
minutes, instead of the week it used to take in the System 7 days.
--
Rainer Brockerhoff <[EMAIL PROTECTED]>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
Weblog: http://www.brockerhoff.net/bb/viewtopic.php
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/d.sopchak%40comcast.net
This email sent to [EMAIL PROTECTED]
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/aozer%40apple.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
