[Drawkit] Is DrawKit for me?

[Graham Cox]

On 10/05/2009, at 3:48 PM, Brian Bruinewoud wrote:

> The things that I need to do that don't seem to be catered for by  
> DrawKit are as follows:
> 	• Shapes will need to interact with each other: If I drag a shape  
> so that it 'hits' another, both shapes need to do clever stuff so  
> that they don't overlap. What they do exactly is based on the  
> priority of each shape. But if they both had equal priority and were  
> both rectangles of the same height, then their lengths would reduce  
> equally.
> 	• Shapes that touch need to share the same sides. That is, the  
> styles of the path drawn for the side. In fact, where shapes touch,  
> only one of the shapes should draw a path.
> 	• Shapes need to have paths that have styles that vary along their  
> lengths.
>
> Rephrasing my requirements in terms of cartography (given that this  
> is the driving application for Graham's development of DrawKit):  
> Most of the shapes in my app will actually be 'areas', like  
> countries on a continent; states in country; councils in a state;  
> allotments in a council; etc. They have areas that need to cover  
> their parent and share sides but do not overlap and those sides need  
> to have the same attributes.
>
> I guess I could do the first one by subclassing shape and writing  
> another 'boolean-op' type function.
>


Hi Brian,

I'm building a cartography on top of DrawKit, so I have solved many of  
the problems you've identified already. Certainly using DrawKit as a  
basis has worked out fine for me, as it provides all the fundamental  
drawing capabilities that the more advanced functions can be built on.

However, the amount of work needed on top of DK for the cartography  
objects is very considerable. So far I've been working on it 4-5 very  
long days per week for well over a year, and DK was previously several  
years work (though less intensive). I'm getting close to a 1.0 release  
though.

I can't share the cartography work I'm doing because it's a commercial  
venture and obviously it would be giving away our IP. All I will say  
is that building on top of DK works, works well, and saves a lots of  
time compared with starting from scratch.

Boolean-op type functions are fraught with pitfalls and are way less  
easy to implement reliably than they look, but yes, you'll need to do  
something in that area for shared boundaries and so on. Varying styles  
along a path is more straightforward, though again has some  
interesting challenges. What do you do where styles invoke differing  
stroke widths for example?

To give you some idea of the code proportions, DK is about 1/3 of the  
total code in the cartography app.

--Graham