Re: NSRulerView and inches
On Jan 21, 2010, at 16:26, Graham Cox wrote: > 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'm taking the middle ground. I think both approaches are perfectly feasible, and I'd choose the one, in any given project, that takes less lines of code. I suspect that in DrawKit, most of what you draw is "content" that needs to be scaled, but in the project where I futzed around with this, most of what I drew was "structural" and didn't need to have its line thicknesses, handles, etc scaled. We each chose the perfect approach for the problem at hand, did we not?? ;) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: NSRulerView and inches
On 22/01/2010, at 2:13 PM, Kyle Sluder wrote: > But that's different from blithely drawing the > resize handles at whatever scale AppKit has calculated for you. I didn't say I was. AppKit doesn't decide on the scale, the user does. Appkit merely sets up a transform to suit. The resize handles are carefully drawn in accordance with the scale according to the rules I want to apply - in my case at 33% of the zoom scale, within certain limits. It would also be possible to draw them always at the same scale (1:1) or at one of several fixed sizes if I wanted. At no point is anything not under the control of the programmer. > My preferred solution: ditch NSRulerView. :) That does seem to me to be throwing the baby out with the bathwater. I guess if I wanted to heavily customise NSRulerView it might be easier to start from scratch, but the built-in class is not bad as far as it goes, and does do a great deal of really tedious work for you. So, what it boils down to is: a) roll your own view scaling/zooming and you have to implement your own rulers, or: b) use the built-in view scaling/zooming and you have to implement your own resize handles or other "scale-proof" UI widget drawing. Seems as broad as it's long to me, though I still favour (b)! --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: NSRulerView and inches
On Thu, Jan 21, 2010 at 5:37 PM, Graham Cox wrote: > OK understand, but why, when NSView does it for you using > -scaleUnitSquareToSize:? Because it makes drawing things consistently at 1:1 resolution easier. > Agree, if you always draw the resize handles at the same fixed size. However, > I found that usability was improved noticeably when these elements are > allowed to scale, but only in some smaller proportion of the main zoom > factor. For example, I use 33% of the main zoom as the scale factor for > resize handles, except if the view is zoomed out in which case a limit is > applied so that the handles do not become smaller than a certain size. > There's also a limit applied at the upper end as well. This makes sense for > general graphic manipulation, though possibly not for every conceivable case > however (e.g. I don't use focus rings as a highlighting method for "content"). I could see small/normal/large resize handles... I think Graffle makes the resize handles smaller when the object itself is small (due to geometry or zoom). But that's different from blithely drawing the resize handles at whatever scale AppKit has calculated for you. > I guess it's not going to make a huge difference whether you apply your own > transform to the "content" drawing or let NSView do it, the content gets > drawn correctly either way. However, if you do handle your own transform, > doesn't the ruler scaling management become really painful? I'm just asking - > I haven't tried this approach so I haven't explored what you have to do with > the rulers to make this work. My preferred solution: ditch NSRulerView. :) --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: NSRulerView and inches
On 22/01/2010, at 12:04 PM, Kyle Sluder wrote: > I would have a separate "zoomFactor" property on my view, Yes, so would I... > and use that > inside -drawRect: to create a scaling transformation. OK understand, but why, when NSView does it for you using -scaleUnitSquareToSize:? > 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? Agree, if you always draw the resize handles at the same fixed size. However, I found that usability was improved noticeably when these elements are allowed to scale, but only in some smaller proportion of the main zoom factor. For example, I use 33% of the main zoom as the scale factor for resize handles, except if the view is zoomed out in which case a limit is applied so that the handles do not become smaller than a certain size. There's also a limit applied at the upper end as well. This makes sense for general graphic manipulation, though possibly not for every conceivable case however (e.g. I don't use focus rings as a highlighting method for "content"). I guess it's not going to make a huge difference whether you apply your own transform to the "content" drawing or let NSView do it, the content gets drawn correctly either way. However, if you do handle your own transform, doesn't the ruler scaling management become really painful? I'm just asking - I haven't tried this approach so I haven't explored what you have to do with the rulers to make this work. > There are lots of things Cocoa does for you automatically that are 80% > solutions. NSController, anyone? True, but in this case I haven't found a need to do much other than standard with NSRulerView. I just set the rulers to match my base coordinate system and it truly "just works". > No, I think you understood me (or at least you were aware of the > method I prefer). Well, I do now. I think it's a relatively small difference after all - I thought you might have been talking about a much different approach, so thanks for the clarification. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: NSRulerView and inches
On Thu, Jan 21, 2010 at 4:52 PM, Graham Cox 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 (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: NSRulerView and inches
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"? 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. Surely any other design is going to be more work? 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! --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: NSRulerView and inches
On Thu, Jan 21, 2010 at 4:26 PM, Graham Cox wrote: > 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. I disagree wholeheartedly. I'd use automatic frame/bounds scaling for resolution independence, but manually track scale factors for zooming. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: NSRulerView and inches
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 (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: NSRulerView and inches
On Jan 21, 2010, at 04:30, Milen Dzhumerov wrote: > I'm been involved with an app that has the ability to create documents in > various dimensions, including a way where you specify the width and height in > inches + the PPI. So, for example, the user can specify a document of size > 5in x 5in with 300 PPI. From this definition, I'll have a document of size > 1500 points by 1500 points although I'll have to redefine how many points > equal one inch for the ruler view. > > As NSRulerView already has the definition of 1 inch = 72 points, am I right > that I'll have to create a new unit with a random name (could use a UUID) and > "in" abbreviation that's defined from the PPI selected by the user? So, in > the example case I'll send a msg similar to [NSRulerView > registerUnitWithName:@"random unused unit name" > abbreviation:NSLocalizedString(@"in", @"Inches abbreviation string") > unitToPointsConversionFactor:300.0 stepUpCycle:upArray > stepDownCycle:downArray]. No, the first "P" in PPI isn't "points" but "pixels". A 5in x 5in x 300 PPI document is 1500 pixels by 1500 pixels. By contrast, rulers work in [Postscript] points -- 1/72.0 in. Registering a new unit with the parameters you describe would make your inches 4 times too large, approximately. It doesn't look like you need any new ruler definitions for your situation. 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. The details depend on your application, but it's vital to start by clearing separating the data model coordinate system from the view's logical and actual coordinate systems. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
NSRulerView and inches
Hi all, I'm been involved with an app that has the ability to create documents in various dimensions, including a way where you specify the width and height in inches + the PPI. So, for example, the user can specify a document of size 5in x 5in with 300 PPI. From this definition, I'll have a document of size 1500 points by 1500 points although I'll have to redefine how many points equal one inch for the ruler view. As NSRulerView already has the definition of 1 inch = 72 points, am I right that I'll have to create a new unit with a random name (could use a UUID) and "in" abbreviation that's defined from the PPI selected by the user? So, in the example case I'll send a msg similar to [NSRulerView registerUnitWithName:@"random unused unit name" abbreviation:NSLocalizedString(@"in", @"Inches abbreviation string") unitToPointsConversionFactor:300.0 stepUpCycle:upArray stepDownCycle:downArray]. Thanks, M___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
