Re: Strange toolbar/view/resize cursor interaction
Re: Strange toolbar/view/resize cursor interaction
- Subject: Re: Strange toolbar/view/resize cursor interaction
- From: Eric Shepherd <email@hidden>
- Date: Tue, 22 Apr 2014 18:36:43 -0400
So, here's a weird thing I've just now noticed:
When the cursor is at the top edge of my window, the Y value is off by 10
pixels.
When the cursor is at the bottom edge of my window, the Y value is off by
40 pixels.
What the...?
Eric Shepherd
Gmail: email@hidden
Twitter: sheppy
On Tue, Apr 22, 2014 at 12:55 AM, Quincey Morris <
email@hidden> wrote:
> On Apr 21, 2014, at 18:28 , Kyle Sluder <email@hidden> wrote:
>
> Why not?
>
>
> Let’s assume for the sake of an example, the toolbar is 40 points high,
> and the OpenGL view (its visible rect, at least) is 200 points high.
> According to Eric, when the cursor is 40 points *above* the bottom of the
> view, where.y is 200, in view bounds coordinates. That seems to me to mean
> one of 3 possible things:
>
> — When the cursor is at the top of the visible rect, where.y is 40, so
> that the vertical extent of the visible rect is 40..240 in bounds
> coordinates. If the visible rect is the entire view, that means the bounds
> origin is (0, 40). [Or perhaps (0, -40), my brain’s too tired to work it
> out.]
>
> — Or, if the entire view is bigger than the visible rect, the bounds
> origin can be (0, 0), and the vertical extent must be 0..240, with the top
> 40 points clipped.
>
> — Or, if where.y is 0 with the cursor at the top of the visible rect, and
> where.y is 200 at a position 40 points above the bottom of the visible
> rect, then the view vertical extent is 0..240 (bounds coordinates) in a
> frame rect of height 200, and therefore the bounds has been scaled.
>
> Otherwise, how can where.y be 200 at a point 40 (bounds coordinates)
> points above the bottom of a view that’s 200 (frame coordinates) points
> high?
>
> On Apr 21, 2014, at 18:44 , Ken Thomases <email@hidden> wrote:
>
> Just in general, in the majority of cases the bounds origin is (0, 0) and
> its size is equal to the frame size (although for OpenGL views, it's the
> frame size in pixels rather than points). Outside of scrolling, it's
> relatively rare to transform a view's bounds. I think Quincey has gotten
> himself turned around on this.
>
>
> Unless I’m doubly confused, therefore, I don’t think I’m turned around. If
> the bounds origin isn’t (0, 0) or the height in bounds coordinates is
> greater than the height in frame coordinates, it’s certainly unexpected,
> and I’m suggesting that the real problem is whatever brought that
> unexpected situation about.
>
>
_______________________________________________
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