Re: The mouse is where, again?
Re: The mouse is where, again?
- Subject: Re: The mouse is where, again?
- From: "Hamish Allan" <email@hidden>
- Date: Mon, 28 Jan 2008 19:21:56 +0000
On Jan 28, 2008 6:51 PM, Jayson Adams <email@hidden> wrote:
> Q.M. originally asked how you get the current mouse location. I
> spoke up, and he mistakenly decided I was answering his entire post.
> Sorry I tried to help. Please continue on your trek in the wilderness.
No need to be sarcastic -- Quincey asked for the *correct* mouse
location, not the current one, and if you re-read the original post,
you'll find that he spelled it out for you:
On Jan 25, 2008 10:51 PM, <email@hidden> wrote:
> -- Getting the current mouse location using Carbon (if there is a
> function for that) isn't the answer, because that's going to tell me
> where the mouse is *right now in real time*, while the information I
> need is where the mouse is *synchronized with the event stream*. (If
> I'm about to receive a flood of mouseMoved: or mouseDragged: messages,
> I want to know where the mouse is before them, not after. Unreceived
> messages represent the future, I'm still in the present.)
Not to mention that he thanked you for your partial answer -- it was
*you* who subsequently claimed that your answer was complete.
On Jan 28, 2008 6:51 PM, Jayson Adams <email@hidden> wrote:
> If you guys want to pay attention to the mouse location in the event,
> GO AHEAD. You'll get cool behavior like you see in Safari where a
> bookmark bar item is lit up even though the mouse isn't over it. Or
> in a drag loop your selection rect will continue to flop around after
> the user has stopped moving the mouse. You guys obviously know this
> stuff better than I do.
What makes you think that this behaviour is due to trying to stay
synchronised to the event queue, when Quincey has given a clear
explanation of why this sort of behaviour is exactly what you would
expect when you *don't* stay synchronised?
On Jan 28, 2008 6:51 PM, Jayson Adams <email@hidden> wrote:
> The mouse won't move that fast.
>
> My code won't go that slow.
According to this logic, there is never any need to use a queue for
event processing. This is patently untrue.
> If I really care about this thought experiment, I can sweep the queue
> for a mouse up event before I act on a mouse move
Quincey was asking why it should be so complicated to do this
seemingly simple thing. If it behaved as he suggested (that "there
should be a more-or-less immediate message (either mouseEntered: or
mouseExited:) to tell me where the frameworks thinks the mouse is?" --
which seems like a reasonable expectation), sweeping the queue
wouldn't be necessary.
> (BTW, if this
> discussion was about tracking rects, how did it devolve into a
> discussion of mouse drags?).
When you said "If I'm dragging out a selection rect, for example, it's
a bug if the corner of the selection rect is not always under the
mouse.for example", Quincey tried to explain *in terms of your own
example* why the synchronisation is important.
Hamish
_______________________________________________
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