On 22/01/2010, at 7:00 AM, Quincey Morris wrote: > In your data model, keep your sizes and locations in whatever units make the > most sense, then expect to *transform* the values to view units (which > depend, at least, on the view's zoom factor). In general, it's awkward to let > the view do the scaling automatically (by manipulating the relationship > between its bounds and its frame), because you often want to draw your view > contents scaled in both size and location, but your UI widgetry (such as > selection handles) using unscaled sizes on scaled locations.
Note that rulers automatically deal with the view's zoom so you don't normally have to factor that in manually. I'd say that letting the view do the scaling is definitely the easiest way to do it, through its -scaleUnitSquareToSize: method. It's true that elements such as selection handles and whatnot probably need to compensate for the view scale in the opposite direction, but it's probably better to apply that "unzooming" to the selection handles when they are drawn as a special case rather than the general scalable content. I also found that cancelling out the zoom altogether for handles is less usable than allowing them to scale in some proportion to the main zoom, e.g. at about 1/3rd the rate. That keeps them small enough not to block out the things they are associated with but still large enough to see and hit when zoomed in. A simple zoomable view class that I've used in a few projects now is here: http://apptree.net/gczoomview.htm --Graham_______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
