[Drawkit] Questions on control knobs

[Brad Larson]

On Jun 24, 2008, at 12:32 AM, Graham Cox wrote:

>
> On 24 Jun 2008, at 1:28 pm, Brad Larson wrote:
>> 2) For a shape with custom control points, such as an arc, would it  
>> be best to remove all knobs and instead create specific hotspots  
>> corresponding to the start, end, and center of the arc?  I guess  
>> I'm not quite sure when to rely on the DKKnobs and when on the  
>> hotspots, or are they interchangeable?
>
>
> Well... I'm actually not that happy with the current implementation  
> of hotspots. The theory is that because they are supported by any  
> (shape) object, you can add custom hotspots for special uses without  
> subclassing - you attach a hotspot and it will call some delegate  
> object to do the necessary manipulation work on the object. In other  
> words it's a way of attaching a mouse-driven controller to an object  
> for special needs. That's OK, but the details of how hotspots work  
> could do with some improvement to make them easier to use. Also, be  
> aware of a numbering conflict in hotspots that I have fixed since  
> the beta 3 release - it causes some problems with the distortion  
> transformations. (An easy workaround is to force your hotspot  
> partcode numbering to start > 32768).
>
> There is a case for making the standard knobs and extra hotspots one  
> and the same thing, but they aren't at the moment because hotspots  
> were added as a bit of an afterthought. I'll need to think carefully  
> about whether that can be done without disrupting things too much,  
> and if it's worth it.
>
> If you are subclassing an object, be it shape or path, you can  
> implement whatever knobs you want without using hotspots. Note that  
> hotspots only work with shapes at the moment (another thing that  
> maybe ought to be revised).
>
> For the case of an Arc, I'd subclass DKDrawablePath since it already  
> knows how to draw an arc, but replace the standard selection with  
> one based on your own custom knobs (presumably for radius, start and  
> end angles). For roundrects, hotspots are a reasonable choice (for  
> corner radius I'm assuming), for circles - really a special case of  
> a constrained oval, which can be easily achieved by forcing the  
> aspect ratio constraint in your drag method. So it may be that each  
> different type of object needs a slightly different approach.
>
> Quite a bit of the stuff to do with extending and customising knobs  
> hasn't been extensively tried - so far my own projects don't greatly  
> redefine a shape for example, so be prepared for a bit of pain as  
> unexpected bugs pop out of the woodwork in this area. I'll be very  
> keen to address any that come up though, so do keep me informed.


I'm not quite sure how or where to set up and use the DKKnobs in my  
custom subclass.  Attached is my fumbling attempt at creating an arc  
subclass that has three control points: center, starting point, and  
ending point.  The idea is that you could drag around the center point  
to set the radius (it would need to be constrained to be equidistant  
from the starting and ending points), and the starting and ending  
points to set the starting and ending angle.  After dragging one of  
the points, the internal Bezier path would be regenerated to fit the  
new values.  centerPoint, startingPoint, and endingPoint are NSPoint  
properties, and startingPointKnobPartCode and endingPointKnobPartCode  
are integer properties.

I can display my custom control points at the right place by  
overriding drawControlPointsOfPath:usingKnobs: , draw the shape  
properly using the arcCreateLoop: method (called from a custom drawing  
tool), and adjust the control point properties using moveByX:byY: on  
the movement of the whole object.  However, I can't figure out how to  
assign a partcode to my custom center point and retrieve the existing  
partcodes within the Bezier path for the control points present at the  
beginning and ending of the path.  I tried using hitPart: using the  
starting and ending point coordinates at the end of the arcCreateLoop:  
method, but that returns -1.  If I had those partcodes, I believe that  
I could change the control point properties in mouseDraggedAtPoint:  
inPart:event: in response to dragging on the control points.

Am I going about this the right way in my subclass or are there other  
methods that I should be overriding to achieve this behavior?

Also, I noticed that the control point I'm drawing for the center  
point does not always refresh properly in redrawing the object,  
probably because it's outside of the object path and therefore its  
area is not being invalidated.

Sorry about the messy code, I thought the sample would provide a  
better illustration of what I'm attempting.
______________________
Brad Larson
SonoPlot, Inc.
3030 Laura Lane, Suite 120
Middleton, WI 53562

-------------- next part --------------
A non-text attachment was scrubbed...
Name: SPDrawableArc.m
Type: application/octet-stream
Size: 10194 bytes
Desc: not available
URL: <http://lists.apptree.net/pipermail/drawkit-apptree.net/attachments/20080624/80cf834c/attachment.obj>
-------------- next part --------------