[Drawkit] File format extensions

[Brad Larson]

On May 21, 2008, at 5:54 PM, Graham Cox wrote:

>
> 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.
>

At WWDC, I spent some time in the labs and had someone walk me though  
enabling UTIs in an application.  You need to export a custom type in  
your info.plist using syntax similar to the following:

	<key>UTExportedTypeDeclarations</key>
	<array>
		<dict>
			<key>UTTypeConformsTo</key>
			<array>
				<string>public.xml</string>
			</array>
			<key>UTTypeDescription</key>
			<string>SonoPlot's proprietary XML pattern file type</string>
			<key>UTTypeIdentifier</key>
			<string>com.sonoplot.pattern</string>
			<key>UTTypeTagSpecification</key>
			<dict>
				<key>public.filename-extension</key>
				<array>
					<string>pattern</string>
					<string>xml</string>
				</array>
			</dict>
		</dict>
	</array>

In this case, I declared an XML-based filetype with the UTI  
"com.sonoplot.pattern" that responds to the extensions .xml  
and .pattern.  I couldn't open some of our old documents with this,  
though.  It was because these old documents had .xml extensions and  
you cannot override the UTI of an extension that's already been  
assigned, in this case "public.xml".  This is an annoyance, because  
something somewhere else in the system could define a UTI with the  
same extension as your files and you'd have to track it down in order  
to make sure that you handled that UTI as well.


>> 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.
>

With this export declaration, if you fill in the UTI field in the  
Info.plist for your filetype, not just the type name, it will now pass  
the UTI in as the ofType: argument  for the file handling methods.  I  
still like the specification of the plain-language type name  
("Drawing", "Pattern", "SVG") in the Info.plist, along with the  
arbitrary definition of extensions that it handles, but I'll see what  
the easiest way would be to do a lookup and to form the correct  
selector.

Also at WWDC, I talked to the chief coder for WebKit's SVG  
implementation and he showed me how we could do SVG import and export  
entirely in WebKit using a part of the engine that I didn't even know  
existed.  I'll get on that as soon as I clean up a last few things in  
our draw client here.

______________________
Brad Larson
SonoPlot, Inc.
3030 Laura Lane, Suite 120
Middleton, WI 53562