[Drawkit] File format extensions

[Eric Jarvies]

Graham,

I would be willing to setup an svn/trac repo for DrawKit, and provide  
read/write access to the server(ssh/etc.).  drawkit.net domain is  
available, so that could be registered, and the repo could be given  
svn.drawkit.net / trac.drawkit.net(or whatever).

Eric


On May 15, 2008, at 7:38 PM, Brad Larson wrote:

> On May 15, 2008, at 7:41 PM, Graham Cox wrote:
>
>> 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.
>>
>
>
> Yeah, sorry about the independent hosting.  I had changed a few  
> files in the framework and just wanted you and others to be able to  
> download a complete, buildable version so that you could see what I  
> was trying.  Submitting changes as independent source files to the  
> list should be perfectly fine going forward.
>
> The cleanup comment just came from your earlier conversion from the  
> GCDrawKit to DrawKit naming.  I had mistakenly assumed that those  
> files were left as GC had just not been converted over yet.  Believe  
> me, I know the problems that changing names can cause in Objective  
> C.  Try dealing with a multithreaded application using  
> performSelectorOnMainThread calls all over the place which provide  
> no means for GCC to even throw a warning.  Tracking down an error  
> caused by a mistyped selector in one of those can be a real headache.
>
> Aside from that, if you're cool with the file handling methods I'll  
> keep working on those.
>
>
> ______________________
> 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