[Drawkit] Questions on control knobs

[Graham Cox]

On 24 Jun 2008, at 1:28 pm, Brad Larson wrote:

> It looks like the best route to add shapes that can have their  
> properties modified later (such as arcs, circles, and rounded  
> rectangles) is to subclass DKDrawableShape, so I'm doing that and  
> starting to work with control knobs and I had a few scattered  
> questions / comments:
>
> 1) If I wanted to remove the rotation control from a drawn  
> rectangle, is there an easier way to set which control knobs are  
> shown than subclassing DKDrawableShape and overriding the knobMask  
> method with something like
> + (int) knobMask
> {
> 	return 	kGCDrawableShapeAllSizeKnobs;
> }
> ?  It seems like a lot of work to create a subclass where I'm  
> overriding only one method.  Am I missing a property that can be set  
> after the DKDrawableShape is created?


This is the currently intended way to customise which of the shape's  
standard knobs are shown. The thinking is that if you are subclassing  
for some special behaviour, you can also subclass this method too, if  
need be. If you just want to hide the rotation knob and do nothing  
else, yes, it probably seems a bit of a clunky way to do so. Maybe the  
knobmask should be a property of the object, taking its initial  
default from the class?

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

> 3) It looks like DKDrawableShape+Hotspot.h is not included as a  
> framework header, and is commented out in the DKDrawKit.h header  
> file.  Is there a reason for this?  The framework seems to operate  
> correctly with the header included.

I forget the exact problem, but I thought it was because the header  
was already included by another header - but I can't see where right  
now. Even if that's the case it *shouldn't* cause a problem... so  
simply re-enabling it should be OK. I've done that here and it seems  
fine.



cheers, Graham