Re: Need for a creator code?

FROM : Ali Ozer
DATE : Wed Apr 02 18:42:07 2008

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_removed> wrote:

>>> From: Andrew Farmer <<email_removed>>
>>> References: <<email_removed>>
>>> In-Reply-To: <<email_removed>>
>>> Date: Tue, 1 Apr 2008 13:26:58 -0700
>>> Message-ID: <<email_removed>>
>>>
>>> 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_removed>>
>> 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 (<email_removed>)
>>
>> 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.<email_removed>
>>
>> This email sent to d.<email_removed>

>
> _______________________________________________
>
> Cocoa-dev mailing list (<email_removed>)
>
> 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/<email_removed>
>
> This email sent to <email_removed>