[Drawkit] File format extensions

[Graham Cox]

On 22 May 2008, at 12:55 am, Brad Larson wrote:

> I've been testing this against the 10.5 SDK, and if you leave the  
> UTI field out if the Info.plist, the typeName handed to the method  
> is the name of the type, not a UTI.  When I specify a UTI, it won't  
> even drop into the readFromData:ofType:error: method, it just says  
> that the application cannot handle that type.  I've started reading  
> through the documentation on UTIs, but it's giving me a headache.

Yes, me too - I must admit it's not quite "gelled" yet and my attempt  
so far resulted in an inability to open any file. The problem is that  
the makeup of the info.plist file is not DrawKit's to dictate - the  
host app will have its own ideas, so DK needs to work properly  
whatever route the app takes.

> I found a discussion of this here: http://www.mail-archive.com/bibdesk-develop@lists.sourceforge.net/msg00319.html 
>  .  A relevant quote is
>
> "UTI support is all or nothing, which sucks for us. If we had a few  
> proprietary binary formats, this would likely be great.
>
> > It seems to me, looking at the release notes, that it is impossible
> > to handle custom template types using UTIs in Leopard.
>
> I don't know that it's impossible, but it's certainly unpleasant and  
> would definitely require a lot of work and testing for no gain. I  
> like UTIs and I hate the mix of document type/file extension that's  
> used in 10.4 and earlier, but I'd rather have just seen a new  
> document class altogether."
>
> I know UTIs are supposed to be the future, but it seems so much  
> easier to just use the document type names.

One thing is that UTIs are actually supported on 10.4, so it looks as  
if having conditional code won't be needed if the UTI problem as a  
whole can be solved. That wasn't clear before - though I think UTIs  
are more prevalent on 10.5 so they are pushing us this way like it or  
not.

I will give this some more thought and testing - but I do think that  
factoring the type -> method name lookup into a separate method would  
be wise even if it ends up simply wrapping your stringWithFormat:  
approach initially - it makes it much easier to adapt to a look-up  
table if needed without disturbing anything else. But even with simple  
document types I'd use the table, because it allows a many-to-one  
mapping which the string conversion doesn't.

cheers, Graham