[Drawkit] Questions on control knobs

[Graham Cox]

On 26 Jun 2008, at 6:32 am, Brad Larson wrote:

> Excellent.  I had to tweak a few things here and there, such as  
> changing the name of kDKDrawingEntireObjectPart to  
> kGCDrawingEntireObjectPart, adding the DEGREES_TO_RADIANS and  
> RADIANS_TO_DEGREES macro, and changing the name of pathCreationMode  
> to pathEditingMode, to match it up with the heavily patched Beta 3  
> version of DrawKit that I have here, but it works like just like  
> what I was attempting.


I really need to get a new beta posted, as with the latest round of  
name changes and so on there is ever greater divergence. Sorry for the  
inconvenience... of course there will be more for your app next beta  
because of the name changes - but I'm really hoping these will be the  
last ones!

> I like your implementation of the 80% radius control point better  
> than than just using the center (0% radius), it's a lot easier to  
> line up and size an arc that way.

I've actually moved it to be 100% (on the arc itself) which has the  
advantage of tracking the mouse more accurately. There's probably a  
case here for using a custom DKKnob appearance (or adding a new style  
to the existing knob class) that unambiguously indicates the knob's  
function. Also, by angling the knobs to match the local angle, they  
look better and have a more obvious function.

> As far as the radius knob jumping out of alignment, I tracked it  
> down to the averaging you were doing.  Right now, you have it  
> checking to see if only one of the angles is negative, and adding Pi  
> to the radian average of the angles if true.  This causes the angle  
> to just to unexpected values for certain angle cases.  To fix this,  
> I used the following
>
> case kDKArcPathRadiusPart:
> 	angle = ( mEndAngle + mStartAngle ) * 0.5f;
> 	radius = mRadius * 0.8;
> 	if (mEndAngle < mStartAngle)
> 		angle += pi;
> 	break;


Great! I knew it had to be something trivial, but at that time of the  
day (the 3pm slump) my brain just refused to "see" in polar co- 
ordinates ;-)

> Thanks a lot for the help, this should take care of the arc custom  
> shape and I can use this as a basis for the remaining two custom  
> shapes I need to complete the primary features of our draw program.


No problem. It's been a useful exercise for me to see exactly what  
needs to happen to make a subclass of the path object a "first class  
citizen", so that will help improve the documentation. There are a few  
things that I rediscovered. For example:

1. instead of creating the -knobPointForPartcode: method from scratch,  
there is already a -pointForPartcode: method that should be overridden  
(the internals are the same). This also makes sure that object-to- 
object snapping "just works".

2. you need to implement NSCopying and NSCoding so that the object can  
be archived, cut and pasted, copied and duplicated.

3. the angle and radius parameters need to be made undo-aware for undo  
to work properly for those properties.

4. some of the optimisations that DKDrawablePath does to minimise  
update areas actually get in the way for this more "shape like"  
object, so some extra updates had to be inserted
to overcome that. Similarly, the bounds needs to be calculated to  
include all knobs, not just the path.

5. ungrouping arc objects needs further work.

I plan to include this in DK for the next release since now I see it  
in use there's no doubt it's a very useful shape type.

With regard to ungrouping, the current design puts too many  
assumptions about exactly how to ungroup each object type into the  
group class itself. This needs to be refactored so
that the object in question can perform the necessary co-ordinate  
conversion needed to ungroup itself correctly. I'll address this for  
the next beta drop, but for now ungrouping arcs doesn't work correctly.

Attached is the much more polished version which (apart from the beta  
3 incompatible constant names and ungrouping issue) should work fairly  
well.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: DKArcPath.m
Type: application/octet-stream
Size: 15035 bytes
Desc: not available
URL: <http://lists.apptree.net/pipermail/drawkit-apptree.net/attachments/20080626/90007f87/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DKArcPath.h
Type: application/octet-stream
Size: 913 bytes
Desc: not available
URL: <http://lists.apptree.net/pipermail/drawkit-apptree.net/attachments/20080626/90007f87/attachment-0001.obj>
-------------- next part --------------



cheers, Graham