Re: NSRulerView and inches
Re: NSRulerView and inches
- Subject: Re: NSRulerView and inches
- From: Kyle Sluder <email@hidden>
- Date: Thu, 21 Jan 2010 17:04:13 -0800
On Thu, Jan 21, 2010 at 4:52 PM, Graham Cox <email@hidden> wrote:
>
> On 22/01/2010, at 11:38 AM, Kyle Sluder wrote:
>
>> I disagree wholeheartedly. I'd use automatic frame/bounds scaling for
>> resolution independence, but manually track scale factors for zooming.
>
> Seems like I probably haven't made myself very clear then. What do you mean here by "manually tracking"?
I would have a separate "zoomFactor" property on my view, and use that
inside -drawRect: to create a scaling transformation. Drawing UI
adornments (resize handles, focus rings, etc.) at different sizes
depending on zoom is bad UI, particularly when the user zooms out. And
why bother rescaling it back to native size (and potentially dealing
with rounding errors leading to non-integral coordinates and
blurriness) when you could just avoid scaling it in the first place?
> If I have a data model which is a drawing of some form, then letting the view handle the zoom on that data model is correct MVC - the drawing has a fixed coordinate system that never changes no matter what the view's zoom factor or even if there are multiple views of the same model having different zoom factors - the model doesn't need to know or care about the view(s). The only point in the system where the view's actual zoom is needed to be known is when drawing UI widgets such as selection handles, which as Quincey says, do not typically want to be drawn zoomed, so applying a scale factor of 1/zoom to these elements is needed. Since rulers automatically take into account a view's zoom to correctly display the underlying coordinate system at the correctly reported size, that suggests to me that Cocoa actively encourages you to take this approach.
There are lots of things Cocoa does for you automatically that are 80%
solutions. NSController, anyone?
> Surely any other design is going to be more work?
Yep, but it's the difference between "good" and "good enough."
> I think we are talking at crossed purposes. If you have a very different architecture in mind, please explain it, because if I'm missing something obvious after all this time I'd dearly love to know about it!
No, I think you understood me (or at least you were aware of the
method I prefer).
--Kyle Sluder
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden