[Drawkit] Is DrawKit for me?

[Brian Bruinewoud]

On 11/05/2009, at 10:33 , Graham Cox wrote:
> 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

Hi Graham,

I know you're writing a cartography app, that's why I framed the  
questions that way :)

I'm intending to do a simple architecting app. As such the 'areas' are  
often going to be rooms and the paths that surround them will need to  
differ to indicate windows and doors and such. The selection of styles  
will be under control of the app so I should be able to keep away from  
strokes with different widths. You say 'varying styles along a path is  
more straightforward' - could you give me a pointer to which class(es)  
I might need to sub-class or whatever?

As for the changing of area sizes which is really taking the wall  
between two rooms and moving it: increasing one rooms size while  
decreasing the other. Would this be best done by treating the rooms as  
shapes (and using the metadata to connect them somehow) or should the  
walls be the main objects? Are rooms the things surrounded by walls or  
are walls the things on the edges of rooms?
Can we discuss the pros and cons?

Thanks,
Brian