[Drawkit] File format extensions

Graham Cox graham.cox at bigpond.com
Thu May 15 17:41:19 PDT 2008


Hi Brad,

This looks like a good approach - drop in categories and they can be  
used automatically.

In terms of rehosting the download, I think that needs to be thought  
about. I'd prefer that there weren't an uncontrolled number of  
branches for the time being. I have an SVN repo ready to go, the  
intention being that you can always get the latest sources by doing a  
checkout/update from there. Problem is this: the current sources are  
hosted on another svn repo. I'd like to move them to the new repo  
without losing the history. I know how that is done when one has  
access to the host directly, but I don't, for either repo. That's why  
it hasn't happened yet, I need to get help or figure it out for myself.

Once that's available, changes like this can be checked in. The  
general idea is that the repo is read-only by default, but if there  
are people specifically working on things I can allow them write  
status. Alternatively code can be submitted through me - I'd also  
prefer to have the final say over whether stuff gets included or not,  
as there are certain compatibility issues that I am better placed to  
judge than most. Which reminds me...

Be wary of the temptation to "clean up" stuff that simply looks like  
an oversight - it generally isn't. I have several projects that depend  
on DK, and while the usage is still definitely small, so do others.  
Changing class names, constants, method names and even ivars can  
easily have an impact that in general terms is unnecessary (and the  
dynamic nature of Obj-C can leave bugs so caused to go undetected for  
a long time). Compatibility is more important than being strictly  
clean. Besides, classes named with a 'GC' prefix are so named for a  
reason - this means they are general purpose classes that are not  
exclusively part of DK - I use them in other projects too.



cheers, Graham



On 16 May 2008, at 9:43 am, Brad Larson wrote:

> Alright, so I was able to implement the changes I suggested for  
> adding hooks for other file formats.  The other file formats can be  
> added as categories on DKDrawing.  These categories need to provide  
> drawingWith[Filetype]: and dataFor[Filetype] methods, with  
> [Filetype] standing for the document type name, as specified in the  
> Info.plist document with your application.  That way, you can add or  
> remove file types easily at the application level, and set what  
> extensions they'll correspond to at that same level.
>
> For example, the header to the current Drawing filetype category is
>
> @interface DKDrawing (FiletypeDrawing)
>
> + (DKDrawing*)				drawingWithDrawing:(NSData*) drawingData;
> - (NSData*)					dataForDrawing;
>
> @end
>
> This works by using selectors in the DKDrawingDocument  
> dataOfType:error: and readFromData:ofType:error: methods as follows:
>
> - (NSData *)			dataOfType:(NSString*) typeName error:(NSError**)  
> outError
> {
> 	NSString *nameOfFiletypeSavingMethod = [NSString  
> stringWithFormat:@"dataFor%@", typeName];
> 	
> 	// If the selector is not there for this file format, throw an error
> 	if (![[self drawing]  
> respondsToSelector:NSSelectorFromString(nameOfFiletypeSavingMethod)])
> 	{
> 		*outError = [NSError errorWithDomain:NSCocoaErrorDomain  
> code:NSFileWriteUnsupportedSchemeError userInfo:nil];
> 		return nil;
> 	}
> 	
> 	return [[self drawing]  
> performSelector:NSSelectorFromString(nameOfFiletypeSavingMethod)];
> }
>
> with similar code being used for the loading end of things.  This  
> does a check first to make sure that the file format is supported  
> via the framework's categories or the application's categories,  
> throwing an NSError and aborting if not.  You can try this out by  
> adding a different file type to the Properties (accessible through  
> the Target tab in XCode) or Info.plist of DrawDemo and see how it  
> handles the loading and saving of supported and unsupported formats.
>
> A modified version of Beta 3 with this framework in place is  
> currently being hosted at http://www.sonoplot.com/downloads/drawkit.tar.bz2 
>  , but that might not last long.  I'll find a better place to post  
> additions.
>
> Let me know if you feel this is not the right way to implement new  
> file formats and I'll rethink the interface.  Otherwise, I'll  
> proceed with the SVG import / export capabilities and our own  
> application-specific XML format.
>
> Also, there are a bunch of classes with the "GC" prefix still left  
> in the framework (including the compiled framework itself).  I can  
> clean all those up, if you'd like.
>
> ______________________
> Brad Larson
> SonoPlot, Inc.
> 3030 Laura Lane, Suite 120
> Middleton, WI 53562
>
>
>
> _______________________________________________
> Drawkit mailing list
> Drawkit at lists.apptree.net
> http://lists.apptree.net/listinfo.cgi/drawkit-apptree.net



More information about the Drawkit mailing list