[Drawkit] Grid span issues (was Re: Beta 4 Finally up!)

[Brad Larson]

On Jul 22, 2008, at 8:20 PM, Graham Cox wrote:

> Hi Brad,
>
> Yes, that does seem a bit wonky now you highlight it. I'll be honest  
> - I've started to lose track a little bit of exactly what my  
> intentions were there. I was trying to accommodate your wish that  
> span could be something other than 1; seems I goofed.
>
> So, let me just go back over the basic concepts so I can get it  
> clear in my mind, and we'll see what needs to be fixed.
>
> 1. "Span" is *defined* as the distance in Quartz points for 1 of  
> whatever units you want to use. This number and the units themselves  
> are stored by the DKDrawing object. The grid is then meant to use  
> this basic value as a starting point for setting up and drawing the  
> grid. The reason that the grid no longer stores span is because the  
> drawing is already doing that and I don't want data duplication -  
> the grid should be obtaining this value from the drawing as needed.  
> The reason the drawing has this information is because it still  
> allows "real world" measurements even if you have no grid layer -  
> the grid is intended just to visualise the co-ordinates (and  
> secondarily to provide snapping assistance).
>
> 2. When rendering the grid, you may want to use a multiple other  
> than 1. So if your span was 32 points representing 1km, but you  
> wanted to draw 2km squares, you'd use a span multiplier of 2. It  
> should also be possible to have non-integer multipliers.
>
> I think you're right - the multiplier should be stored separately by  
> the grid. It would be unknown to the drawing object, but taken into  
> account when the grid is set up. Getting rid of the method - 
> setSpanDistance:divisions:majors: and putting everything into the  
> other method would help I think, because it then makes it clear that  
> there is just one place to set this.
>
> So in your case you'd want to set "microns" as the unit, define the  
> distance for 1 µm, then have a multiplier of 1000. That would be a  
> lot simpler than trying to fiddle all the factors yourself. Is that  
> the way you'd like to see it?
>
>

I think so, yes.  Most of the other vector and CAD drawing programs  
I've worked with in the past have just used major and minor grid  
lines, so maybe eliminating the "span" term and going with the  
unitToPointsConversionFactor that is set in the DKDrawing would be the  
way to go.  Then you could set up and draw only the major and minor  
grid lines, and snap to the minor grid lines (if grid snap is on).

In any case, attached are the files for a DKGridLayer that stores the  
span locally, as it did in Beta 3.  Also, I added a workaround in the  
createGridCacheInRect: method for the case where mSpanCycle is 0,  
which leads to an infinite loop and complete consumption of system  
resources.  This happened to me a couple of times when setting a span  
of 10.0 using my small units.

It's a little confusing as to what units (Quartz or drawing) to use  
where, but the following works right now for setting up a grid with  
100 micron spacing for minor lines, 1000 microns for major lines,  
groupings of major units that are 2-wide, and a nice power of 10 step  
up / down on the rulers:

[grid setDistanceForUnitSpan:kSPMicronToPointsConversion  
drawingUnits:@"Microns" span:1000.0 divisions:10 majors:2 rulerSteps: 
10];


> On 23 Jul 2008, at 6:51 am, Brad Larson wrote:
>
>> Thanks a lot for this, there look to be a large number of  
>> improvements under the hood.
>>
>> However, I'm having some problems with the new way that DKGridLayer  
>> handles units and spans.  Right now, it equates a single realspace  
>> unit to the width of a span.  In Beta 3, the two values were  
>> independent.  This causes a problem in our case, where we have  
>> small units (microns), but only want to have spans every 100 or  
>> 1000 microns.  Under Beta 4, the drawing grid for our program is  
>> solid black.  In Beta 3, DKGridLayer would set and read back the  
>> m_spanDistance instance variable, but now only the DKDrawing's  
>> unitToPointsConversionFactor is used.
>>
>> In fact, in DKGridLayer's  
>> setDistanceForUnitSpan:drawingUnits:span:divisions:majors:rulerSteps 
>> : the conversion factor is first set by
>>
>> [[self drawing] setDrawingUnits:units  
>> unitToPointsConversionFactor:conversionFactor];
>>
>> then the following is called to set up the spans:
>>
>> [self setSpanDistance:conversionFactor * span divisions:divs  
>> majors:majors];
>>
>> but in setSpanDistance:divisions:majors: the  
>> unitToPointsConverstionFactor is overwritten by
>>
>> [[self drawing] setDrawingUnits:[[self drawing] drawingUnits]  
>> unitToPointsConversionFactor:unitDistance];
>>
>> where unitDistance was conversionFactor * span from the previous  
>> call.  It seems to me that this should instead be setting an  
>> instance variable for the span distance, as was done before.  It's  
>> a little odd to have the unitToPointsConversionFactor set to two  
>> different values in a row.
>>
>> Am I reading this correctly or is there a way to set a span with a  
>> length other than one unit that I'm missing?
>
> _______________________________________________
> Drawkit mailing list
> Drawkit at lists.apptree.net
> http://lists.apptree.net/listinfo.cgi/drawkit-apptree.net

______________________
Brad Larson
SonoPlot, Inc.
3030 Laura Lane, Suite 120
Middleton, WI 53562


-------------- next part --------------
A non-text attachment was scrubbed...
Name: DKGridLayer.h
Type: application/octet-stream
Size: 6974 bytes
Desc: not available
URL: <http://lists.apptree.net/pipermail/drawkit-apptree.net/attachments/20080723/8bfcd845/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DKGridLayer.m
Type: application/octet-stream
Size: 49324 bytes
Desc: not available
URL: <http://lists.apptree.net/pipermail/drawkit-apptree.net/attachments/20080723/8bfcd845/attachment-0003.obj>