[Drawkit] Handling drawing primitives

[Graham Cox]

Hi Brad,

You're right, once a shape is created it "forgets" what it is - it's  
just a path. As you have identified, arcs in particular would be  
better if they could be edited as an arc. That would require  
subclassing DKDrawablePath to add radius and other parameters.

If all you need to do is to identify what a shape is geometrically  
speaking, (i.e. rect, oval) you could add some sort of constant to the  
metadata which would give you a way to tell what the path *should* be  
without checking checking its geometry. Of course that could easily  
get stale if the user edits the path in any way.

There might be a better solution - I could add an ivar that indicated  
this and made sure it was invalidated on certain edits. Be worth  
exploring what the best solution would be.

cheers, Graham




On 30 May 2008, at 7:57 am, Brad Larson wrote:

> I'm running into a little difficulty in our drawing application  
> regarding primitives, such as arcs, rectangles, and circles.  When  
> loading from our simple XML file format, which specifies simple  
> shapes, I have no problem creating objects, either by helper  
> functions like initWithRect or by creating an NSBezierPath  
> representative of the primitive.  Where I'm having problems are the  
> editing and file saving operations.
>
> For file saving, the only way I can see to access the geometry of  
> the DKDrawableShapes and DKDrawablePaths is through their  
> NSBezierPaths.  This adds a little challenge, because a rectangle is  
> no longer just a rectangle with a length and width, it is now a five- 
> element NSBezierPath (an initial NSMoveToBezierPathElement, four  
> NSLineToBezierPathElements, and an NSClosePathBezierPathElement).   
> You now have to intelligently parse out this structure and recognize  
> that it is a rectangle, calculate the length and width, and write it  
> out to a file.  Circles and arcs are even worse, because there are a  
> variable number of curve points and you have to calculate the center  
> point and radius from the lines defined by the control points.  I'm  
> working on this right now, and I think it's doable, it's just taking  
> a bit of thought.
>
> The part that's really causing me problems is editing these  
> primitives.  The arc drawing tool is really slick, but when it's  
> done it leaves behind a bezier path.  It would make more sense to be  
> able to edit the arc by dragging the ends for the starting and  
> ending angles, as well as the center point.  You could still convert  
> this arc to a path if you really wanted a bezier path to work with.   
> Our machine does not handle bezier paths right now, and the most it  
> can deal with are arcs, so I'd like to keep editing an arc as an  
> arc.  Another example is a rounded rectangle.  Once it is drawn, I  
> don't see a means for changing the rounding radius short of dealing  
> with it as a path.
>
> Could this be handled through subclassing DKDrawableShape?  For  
> example, a DKDrawableArc that has a center point, starting and  
> ending angles (or points), and maybe a clockwise / counterclockwise  
> boolean value could be edited as a shape with specific control  
> points.  The arc DKDrawingTool would create one, and it would  
> simplify the loading and saving process for this primitive.  Similar  
> subclasses could be created for other primitives.  However, I might  
> be missing something about the architecture of the framework that  
> would make this unnecessary.
>
> ______________________
> 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