[Drawkit] Zoom to bounding box

[Mike Caron]

Hi Graham

On Fri, Apr 3, 2009 at 1:04 AM, Graham Cox <graham.cox at bigpond.com> wrote:

>
> On 03/04/2009, at 4:05 PM, Michael Caron wrote:
>
>  I did see in GCZoomView that there was something called "ZoomToRect". It
>> didn't work as I expected it to, however. I'm loading a document from an
>> archived state and when I try to look for the current drawing view from the
>> DKDrawingView class method "currentlyDrawingView", I get a nil back. How
>> does one get the current view so that I can do one of these ZoomToRect
>> calls?
>>
>
> +currentlyDrawingView is used to obtain the view that's currently
> performing drawing - i.e. processing an update. It's only valid within a
> drawing method called from the view's -drawRect: method, and even then there
> are usually better ways to get the view (it's typically passed to all
> higher-level drawing methods). So I think that's a red-herring for you here.


Ah, that's why I'm getting a nil back. Thanks!


> How you obtain the view itself as a ready object will depend on your app
> architecture. Some apps will open multiple windows onto the same drawing, or
> have a splitter with different views of the drawing, or have multiple
> documents open at once. DrawKit makes no assumptions along these lines, so
> it leaves some of the high-level wiring-up to you. For example, a typical
> document based app that only has one view per document might just declare an
> IBOutlet to the main view in the document object and leave it to you to wire
> up in IB. DKDrawingDocument takes this approach for example (and returns the
> view from its -mainView method).
>

I'm working with a subclass of DKDrawingDocument and I think the view stuff
has been kept in tact, so I should be able to use -mainView. Thanks, didn't
notice that method.


> Where possible, use some form of the above to locate the view. Since you
> set up and manage it, it can be however makes the most sense for you.
> Alternatively, but not recommended, you can discover which views are
> ultimately associated with a given DKDrawing by iterating the array returned
> by the -controllers method, and asking each controller for its view. Note
> that the link between a drawing and a view is not magic - you forge that
> connection - unless you're using the automatic drawing creation methodology.
> Even in that case you would still typically have an outlet to the view that
> you can access from a suitable place.
>
>  In the end I just decided to crop the drawing to the shape. I'm new to the
>> framework, so my implementation is probably a bit crude. I keep an array of
>> the drawable objects in my drawing so that I can translate them to new
>> coordinates after resizing the drawing to the size of the bounding box. To
>> translate all the objects, I just used the -(void) DKDrawableObject
>> offsetLocationByX:byY: method.
>>
>
> OK, this is a completely different thing to just displaying the drawing at
> some scale - this actually changes the content of the data model. Are you
> sure this is what you want? If so, then using the -offsetLocationByX:byY: is
> fine to move the objects, but it won't change their size. You can change an
> object's individual size using its -setSize: method, but for scaling
> multiple objects to fit some particular size this would be a lot of work,
> since each object has its own reference point that you'd need to compensate
> for the scale. Working so hard is a sure sign of not really working with the
> framework.


In the end, I was choosing zoom because I thought it would be easier as a
first go at centering the view on the drawing contents. Cropping is what I
ultimately want to do, so yes, changing the content of the data model is
what I want.

However, it seems that I'm still doing something incorrectly here. Suppose,
I have a drawing that is mostly whitespace, except for a few drawable
objects in the lower right corner. Let's say the bounding box on these
objects is at (35,35) and that it's height and width are each 25. Let's say
the drawing itself is 60w x 80h. I want to crop the drawing now to be 30 x
30 with the bounding box contents centered in the middle. It seems that the
way to do this is:

1. Obtain the bounding box of the drawable objects
2. Compute the X and Y translation factor (to move the objects)

2.1. Xoffset = -(boundingbox.origin.x)
2.2. Yoffset = -(boundingbox.origin.y)

3. Resize the document (so margins are created properly)
4. Iterate through the drawable objects and move them using the
-offsetLocationByX:byY method

4.1. xfactor = Xoffset + marginLeft
4.2. yfactor = Xoffset + marginTop


It seems, based on your response that I'll also have to resize each drawable
object since I've changed the size of the document? Do I understand you
correctly?


>
>  I had tried to use the AffineTransforms, but they didn't appear to do
>> anything. Is there a special way to use those? After you apply a transform
>> to all objects in a layer, is there something else you have to do?
>>
>
> It's not clear which affine transforms you are referring to. Transforms are
> used extensively in DK and in many cases in quite subtle ways. Without
> properly understanding them it's likely you'll end up with a broken mess.
> There is a method of DKObjectOwnerLayer that might help you here
> -applyTransformToObjects: which calls each object's -applyTransform: method
> with the transform you supply. This allows you to offset and scale all
> objects in a layer en masse (or rotate all objects around a common point),
> but you still have to know what you're doing with transforms to use it
> effectively. The Cocoa Drawing Guide has some info on the topic, as do most
> texts on computer graphics. To experiment, you could start with a simple
> transform that does a linear translation which should show you the objects
> shifting position. There's nothing special you need to do after calling the
> method - the views should update automatically.
>

Exactly, I was using the -applyTransformToObjects on the layer. But again,
didn't really seem to do anything, so perhaps I have some more learning to
do about transforms. I had seen the Cocoa Drawing Guide, and I'll take
another look at it. Thanks, Graham!

All the best,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.apptree.net/pipermail/drawkit-apptree.net/attachments/20090403/d075008b/attachment.htm>