[Drawkit] Questions on control knobs

[Graham Cox]

On 27 Jun 2008, at 8:27 am, Brad Larson wrote:

> The final arc control design is really slick.  I don't know that  
> I've worked with a vector drawing program that did as good a job as  
> what you have now.

Well that's high praise ;-) thanks!

I've tweaked it some more since and I do like the implementation, very  
usable. I also fixed the ungrouping issue.

> There's just one issue I have with the current implementation, and  
> that's when you are drawing the arc it currently uses a stroke width  
> of 2.0 for the initial radius line.  At the high magnifications that  
> we're dealing with, that becomes enormous.  For someone who is  
> zoomed out, it might also present a problem.  This could be fixed by  
> copying the current style and changing its color to make the  
> temporary stroke style used at the beginning of DKArcPath's   
> arcCreateLoop: method, rather than generating it from scratch using  
> the styleWithFillColour:strokeColour:strokeWidth: method as is done  
> now.  This should be simple, but I can't figure out an easy way to  
> reach into a DKStyle and address its DKStroke so that I can set the  
> DKStroke's properties.

I agree the 2.0 stroke is way too heavy, but in fact I've addressed it  
by losing it altogether. Now that the shape uses the normal selection  
highlighting and DKKnob to do its thing, during the creation phase  
that serves perfectly fine, with no need to hack the style about as  
previously. It also means that the arcCreateLoop function is a lot  
simpler and more straightforward (I do love it when that happens - cut  
out lots of code and it works *better*!).

If you'd like the final source for DKArcPath I'll post it, otherwise  
it'll be in the next drop.

> Additionally, I have one last shape (source attached) that is simply  
> a point.  We use it to represent a single droplet put down by our  
> dispenser, so it's a very simple object that can't be resized, only  
> placed on the drawing and moved.  Internally, its path just consists  
> of a MoveTo the center of the point and a LineTo the same center  
> point.  We use a feature style that has rounded endcaps and is as  
> wide as the droplet would be.  I cribbed most of its code from the  
> DKArcPath example you provided.  I can load and save the object  
> using our XML file handling routines that programmatically create  
> it, drag on its center to move it around, and delete it, but when I  
> go to draw it, I click on the drawing and see it appear, then  
> immediately disappear as I lift up the mouse.  There didn't seem to  
> be a path drawing routine that handled stamping an object onto the  
> drawing, so I repurposed lineCreateLoop:, but nothing leaps out at  
> me as to what's going wrong.  I'll keep digging, but any suggestions  
> as to what I might be missing would be greatly appreciated.

The short answer:

add this overridden method to your point class:

- (BOOL)  objectIsValid
{
	return YES;
}


The long(er) answer:

When DKObjectCreationTool is creating a shape or path, it starts off  
with a size of zero. For most objects, a size of zero at the end of  
the creation operation (mouse up) would mean that a useless object was  
created, so rather than pollute the drawing with such objects (which  
would usually be invisible), it discards it. Whether the object is  
really OK to be added depends on the result from -objectIsValid, so  
the object can determine for itself what it considers to be "valid".  
Check out the implementation in DKDrawablePath and DKDrawableShape for  
examples. For a naked DKDrawableObject, this returns NO by default.

So your point object gets temporarily added by the creation tool, then  
because it thinks it isn't valid at mouse up, it is then discarded.  
That's why it appears then disappears. You can just return YES as  
suggested or figure out a better test.

cheers, Graham