Re: Drawing from upper left
Re: Drawing from upper left
- Subject: Re: Drawing from upper left
- From: Wagner Truppel <email@hidden>
- Date: Tue, 26 Jun 2007 19:35:31 +0200
Ultimately, It doesn't matter to me where it's drawn from. The
important thing is that the offset of subviews from the top of the
window remains constant on window resizes. Conceptually, it's much
easier to think about if the top left corner of views and frames
were the origin. With the origin in the lower left, if you want to
preserve the top offset, you have to recalculate the frames for
every subview on every superview resize. But that's just tilting at
windmills.
You have a good point there, but I seem to recall reading in the docs
that you can programatically set the "springs" that you usually set
using IB. Thus, you could do your custom subview setup in either
coordinate system (non-flipped or flipped) and, if you set the
springs to enforce a fixed separation, you shouldn't have to
recalculate anything when resizing.
I should make a confession. All I said so far is based on reading the
docs. I've not actually tried any of this, so I may be incorrect in
my understanding of the docs. Just thought I'd make that clear.
Incidentally, speaking of the docs, I find the explanation of flipped
in the section "Transforming the Coordinate System" of "View
Programming Guide for Cocoa" <http://developer.apple.com/
documentation/Cocoa/Conceptual/CocoaViewsGuide/Coordinates/
chapter_3_section_4.html#//apple_ref/doc/uid/TP40002978-CH10-
DontLinkElementID_34> and, in particular, Fig. 2.5 to be misleading.
Figure 2.5 shows what happens when you change the flip status on a
NSView that already has something drawn on it. The result is correct,
of course. But that is *not* what one would want to do and is not the
purpose of -(BOOL)isFlipped.
The purpose of allowing the developer to switch to a flipped
coordinate system is to facilitate operating in that system, meaning
that all logical processing should be performed in that system. Thus,
if I were to process an image - such as that shown in Fig. 2.5 - in
the flipped system, I'd do all the processing thinking "upper-left"
and, as a result, the image would *NOT* appear upside down, as shown
in Fig. 2.5. The only reason it *does* appear upside down is because
the image was processed in the non-flipped system and then the system
was flipped. Again, that's not something any sensible developer would
do.
In other words, either a developer thinks "bottom-left" and returns
NO for -(BOOL)isFlipped, *OR* he thinks "upper-left" and returns YES
for -(BOOL)isFlipped. Either way, the actual displayed result should
be the same.
By showing two different results in Figure 2.5, without clearly
explaining why, the documentation ends up being misleading, in my
opinion.
And the above "rant" just made me decide to log a suggestion for
document improvement in that regard.
Wagner
_______________________________________________
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