[Drawkit] Is DrawKit for me?

[Graham Cox]

On 11/05/2009, at 9:25 PM, Brian Bruinewoud wrote:

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

In my case I have a class which allows multiple styles along the  
length of the path, which typically represents a road, watercourse,  
etc. I did that by subclassing DKDrawablePath. However for  
architectural plans geometric shapes sound like a possibly better fit,  
so DKDrawableShape could work better there. Or perhaps you could  
design your multiple styles solution so it works more generically with  
any class (after all the standard style model applies to all objects,  
so multiple styles should too - in my case I solved a specific need  
without generalising it however).

Each style along the path is a standard DKStyle, but is encapsulated  
in another object that allows the style to apply to a certain range of  
the path, and each path maintains a list of these, sorted by distance.  
I also do deal with the varying widths issue by inserting transitional  
styles on the fly that blend one stroke into another using some  
moderately complex algorithms that ensure that the transitions are  
always smooth even when the underlying path is curving and also when  
the number of stroke components doesn't match. The subclass of  
DKDrawablePath then overrides the -drawContent method so that this  
list of ranged styles draws instead of the normal style. This is the  
sort of thing it can do (this is a single path, not several joined end  
to end):

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Picture 13.png
Type: image/png
Size: 16593 bytes
Desc: not available
URL: <http://lists.apptree.net/pipermail/drawkit-apptree.net/attachments/20090511/d56cdae8/attachment-0001.png>
-------------- next part --------------



Note that one of the changes I made to DK to make this a bit easier  
hasn't been published yet, namely, that many of the relationships  
between drawables, layers, styles and so forth are now expressed using  
formal protocols instead of informal ones, so the compiler can flag  
non-compliance to the protocol. I really should get around to making  
that public soon, along with a host of other fixes. Note that it  
doesn't affect code you write now in compatibility terms, but it does  
make it easier to detect problems, especially when subclassing objects  
that become containers for other objects.

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

Well, the metadata could be used but I have a feeling it would be  
tougher than necessary. Instead, how about a special class of group  
that understood the relationships between the areal objects it  
contained? The standard geometry of a group would keep everything  
together and transformed as needed, and it could embody additional  
smarts that allowed a wall to be moved and so on. One of the things I  
have done quite a bit of is to extend the idea of a "selection" deeper  
into a given object so there are hierarchies of selection. (e.g. you  
could have a wall selection down inside a group). I haven't found the  
partcode model that DK uses to identify hotspots within an object hard  
to extend in this respect - in fact the opposite.

Regarding the walls/rooms question, I think you'd have to develop data  
structures that express the necessary attributes of a room in terms  
that are meaningful to you, then figure out ways to visualise that  
data in terms of paths, strokes, fills and images (which is what  
everything comes down to, as that's all that CoreGraphics draws). DK  
Objects can help by presenting CoreGraphics drawing in terms of  
individual objects that encapsulate the necessary drawing state, but  
if shapes or paths don't cut it, DKDrawableObject can be subclassed  
also - it's more work, but more open-ended. In one or two places I do  
subclass DKDrawableObject where I didn't find either paths or shapes  
to be the right fit for what I needed to do. It's in that area that  
the formal protocols help a lot as it ensures that my entirely custom  
drawables were still happily accepted by the layers, groups and other  
containers they were placed in.

> Can we discuss the pros and cons?

Certainly. Hopefully the above will give you some hints as to how I  
have handled some of these issues. Also, with others here working on  
DXF support, there is a growing knowledge about how CAD-type  
functionality fits into DK.

--Graham