Re: NSView mouseDown truncated coordinates
On Feb 23, 2012, at 14:15 , Markus Spoettl wrote: Mouse movement highlighting must happen when the mouse moves. At that time, only the mouse move coordinates are known. They correspond with what happens on the screen, so highlighting works as expected. Now a mouse-down comes along with different coordinates. That change in coordinates is not reflected visually on screen (no cursor movement, no highlight changes). It leads to other objects than the one highlighted one being manipulated. Really confusing to the end user. What I'm saying is, have mouseDown invoke cursorUpdate with the mouseDown event, so that if the position is different from the last real cursorUpdate/mouseMoved, the highlighted item will change to the item that's being dragged. That may sound wrong, but it's the same behavior as if the mouse was really moving when you pressed the button. Would I be correct in saying that the behavior you're asking for is as follows? The mouse location reported in any event following mouseMoved or mouseDragged (except another mouseMoved or mouseDragged, of course) must be the same as the mouse location reported by the preceding mouseMoved or mouseDragged event. Although the above might have been mostly true in the past, I doubt it was ever guaranteed in any way. However, even if it were true (or for that matter, even if your mouseDown called cursorUpdate/mouseMoved), it wouldn't truly solve your problem. It would mean that the dragged item is highlighted, not that the item the user attempted to click on (and was highlighted at the start of the attempt, perhaps) is dragged. See what I mean? PS: None of your or my replies seem to make it through to the list although both you an I cc the list. Not sure why that is. I think the list is just still slow. Or again. Other things are coming through. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSView mouseDown truncated coordinates
Hello,
On 28.11.11 15:40, Richard Somers wrote:
However, the mouseDown and mouseUp events always produce truncated
coordinates.
e.g. x:140.00 y:128.00
This causes inaccuracy with hit testing between mouseMoved and
mouseDown.
Using floor, ceil, or round on the returned value does not work
because the value can be off by as much as +-1.0.
Little late into this but I'm curious, did you manage to come up with a
solution for the issue (I just ran into the same issue)?
As an illustration for the list, I have logged coordinates of a mouse
move and a subsequent mouse down event that followed the move event:
mouseMovedToPoint:NSPoint: {217.15625, 343.3984375}
mouseDownAtPoint:NSPoint: {217, 344}
So it can happen that the hit-tests in -mouseMoved: and -mouseDown:
return different objects in my view's object tree (which happens
surprisingly often, btw.).
Anyone know how the system works out the integral coordinates?
Regards
Markus
--
__
Markus Spoettl
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSView mouseDown truncated coordinates
On 28.11.11 15:40, Richard Somers wrote:
I'm using a NSTrackingArea in a view to receive mouseMoved events.
The cursor location in the mouseMoved and mouseDragged events have
non-integer coordinates (as expected). e.g. x:140.601562
y:128.082031
However, the mouseDown and mouseUp events always produce truncated
coordinates. e.g. x:140.00 y:128.00
This causes inaccuracy with hit testing between mouseMoved and
mouseDown.
On Nov 26, 2011, at 10:58 AM, Ken Thomases wrote:
We've seen this, too. It started happening with Lion.
Using floor, ceil, or round on the returned value does not work
because the value can be off by as much as +-1.0.
The amount of error in the value returned can be somewhat random. It
is not constant.
Little late into this but I'm curious, did you manage to come up with a
solution for the issue (I just ran into the same thing)?
As an illustration for the list, I have logged coordinates of a mouse
move and a subsequent mouse down event that followed the move event:
mouseMovedToPoint:NSPoint: {217.15625, 343.3984375}
mouseDownAtPoint:NSPoint: {217, 344}
It can (and does) happen that the hit-tests in -mouseMoved: and
-mouseDown: return different objects that my view displays. My objects
can be very close to each other and 1 pixel actually makes a difference.
Anyone know how to work out mouseDown coordinates one can expect to get
when looking at mouseMove coordinates?
Regards
Markus
--
__
Markus Spoettl
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSView mouseDown truncated coordinates
On Feb 23, 2012, at 04:04 , Markus Spoettl wrote:
As an illustration for the list, I have logged coordinates of a mouse move
and a subsequent mouse down event that followed the move event:
mouseMovedToPoint:NSPoint: {217.15625, 343.3984375}
mouseDownAtPoint:NSPoint: {217, 344}
It can (and does) happen that the hit-tests in -mouseMoved: and -mouseDown:
return different objects that my view displays. My objects can be very close
to each other and 1 pixel actually makes a difference.
Anyone know how to work out mouseDown coordinates one can expect to get when
looking at mouseMove coordinates?
I'll ask the stupid question:
How do you know (or, why do you assume) that these two sets of coordinates
represent the same point? Even if the user did a press-and-hold, a
high-resolution input device might detect some movement in the position. (At
a sub-pixel level, I guess everyone has fat, wobbly fingers.)
Or, looking at it from the other end, in many applications it's desirable to
debounce the mouse position at the beginning of dragging, to prevent unwanted
short drags. By debounce, I mean deferring the initial move of the dragged
object until the mouse position has moved by at least a couple of pixels from
the mouse-down position. In such a scenario, a mouse-moved location has to be
co-ordinated with the dragging state. I think your scenario is similar --
whatever code is using the mouse-moved position must take account whether the
mouse is already down.
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSView mouseDown truncated coordinates
On 23.02.12 18:53, Quincey Morris wrote: Anyone know how to work out mouseDown coordinates one can expect to get when looking at mouseMove coordinates? I'll ask the stupid question: How do you know (or, why do you assume) that these two sets of coordinates represent the same point? Even if the user did a press-and-hold, a high-resolution input device might detect some movement in the position. (At a sub-pixel level, I guess everyone has fat, wobbly fingers.) I'm using a mouse and the cursor doesn't move between -mouseMove: and -mouseDown: (on screen). If the device would be capable of reporting sub-pixel movements (which may not be reported by moving the cursor), I guess it would have done so by sending an additional -mouseMove: event. If it didn't, I have to assume it didn't notice any movement and therefore didn't report any. That (maybe flawed) theory asside, I just know that it didn't move because as an operator I made sure of it (when hunting a bug like this, one first assumes operator mistakes, I did too). Up until now ( Lion), it was guaranteed (well, maybe not that, it just happened to work that way) that the -moveMoved: location corresponded to the subsequent -mouseDown: location. That meant that any hover-effects visualized during -mouseMoved: would have been rendered on objects that react in some way when the mouse goes down on them. Of course this can be worked around (maybe by ignoring -mouseDown: coordinates if deemed sensible in the situation). It just complicates things by having to remember more state than was necessary before. And it was a surprise. -- __ Markus Spoettl ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSView mouseDown truncated coordinates
On Feb 23, 2012, at 10:27 , Markus Spoettl wrote: I'm using a mouse and the cursor doesn't move between -mouseMove: and -mouseDown: (on screen). If the device would be capable of reporting sub-pixel movements (which may not be reported by moving the cursor), I guess it would have done so by sending an additional -mouseMove: event. If it didn't, I have to assume it didn't notice any movement and therefore didn't report any. That (maybe flawed) theory asside, I just know that it didn't move because as an operator I made sure of it (when hunting a bug like this, one first assumes operator mistakes, I did too). I think the theory *is* flawed. Just because the pointer stays in the same place doesn't mean that a sub-pixel-resolution device didn't detect a change. Perhaps even the air temperature can change the reading. :) Actually, the theory I was working on was that doing anything physical to the mouse, moving it or pressing on it or pressing on the surface underneath it, could cause the reading to change for a short period of time after the mouse-down was detected. Up until now ( Lion), it was guaranteed (well, maybe not that, it just happened to work that way) that the -moveMoved: location corresponded to the subsequent -mouseDown: location. That meant that any hover-effects visualized during -mouseMoved: would have been rendered on objects that react in some way when the mouse goes down on them. Aha! You fell into my carefully prepared trap! Are you talking about mouseMoved or mouseDragged? If you're talking about mouseDragged, then the variation comes under the heading of debouncing the initial part of the movement, and you should probably be doing that anyway. If you're talking about mouseMoved, then you already have a change of context involved. When the mouse is up, hover-effects should (presumably) refer to which object will be grabbed if you mouse down. When the mouse is down, they should (presumably) refer to which 2nd object the dragged object is being dragged to. If you're relying on mouseMoved to keep the *dragged* object highlighted in some way, I think you're Doing It Wrong™. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSView mouseDown truncated coordinates
On 23.02.12 20:07, Quincey Morris wrote: Up until now ( Lion), it was guaranteed (well, maybe not that, it just happened to work that way) that the -moveMoved: location corresponded to the subsequent -mouseDown: location. That meant that any hover-effects visualized during -mouseMoved: would have been rendered on objects that react in some way when the mouse goes down on them. Aha! You fell into my carefully prepared trap! [...] If you're talking about mouseMoved, then you already have a change of context involved. When the mouse is up, hover-effects should (presumably) refer to which object will be grabbed if you mouse down. When the mouse is down, they should (presumably) refer to which 2nd object the dragged object is being dragged to. If you're relying on mouseMoved to keep the *dragged* object highlighted in some way, I think you're Doing It Wrong™. It's not what I'm doing. This is what I do: 1) On -mouseMoved: locate object under the cursor and highlight it so the user knows which one of them will be operated on when the mouse goes down. 2) On -mouseDown: locate object under the cursor and prepare it for dragging (by remembering it). 3) On -mouseDragged: drag the object selected in (2) Pretty standard stuff. Of course this relies on steps (1) and (2) locating the same object. Apparently one can't assume (1) and (2) produce the same coordinates, although I think that's a bug or at least it's unclear what the relationship of coordinates between mouseMoved: and mouseDown: is. Regards Markus -- __ Markus Spoettl ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSView mouseDown truncated coordinates
On Feb 23, 2012, at 12:09 , Markus Spoettl wrote: This is what I do: 1) On -mouseMoved: locate object under the cursor and highlight it so the user knows which one of them will be operated on when the mouse goes down. 2) On -mouseDown: locate object under the cursor and prepare it for dragging (by remembering it). 3) On -mouseDragged: drag the object selected in (2) Pretty standard stuff. Of course this relies on steps (1) and (2) locating the same object. Apparently one can't assume (1) and (2) produce the same coordinates, although I think that's a bug or at least it's unclear what the relationship of coordinates between mouseMoved: and mouseDown: is. Ah, it's clear now. But I still think your theory is flawed. You can't assume that the physical act of pressing the mouse button doesn't change the reading (that is, doesn't possibly move the mouse slightly). I don't think that the rounding in mouseDown has anything to do with it. All we know is that currently, the mouse can move during the act of pressing down without producing a new mouseMoved, whereas previously it didn't behave like that -- or, not often enough to notice. Incidentally, I have some event-related code that's evolved for years over a series of different apps, and I noticed recently that in its last evolution a couple of years ago, I apparently arranged for all of the common events (mouseEntered, mouseExited, mouseMoved, mouseDown, mouseUp, mouseDragged, keyDown and keyUp) to always call cursorUpdate before doing whatever else they do. That allowed me to consolidate the hover-highlight-detection in one place (cursorUpdate), and gave consistency to the highlighting in cases exactly like the one you're describing. I mention this approach because I worried that (a) calling cursorUpdate additional times might be a performance problem [it isn't, not in any case I've noticed] and (b) there might be a problem passing the event object from a different event to the cursorUpdate method [there isn't, that I can tell]. Maybe you can give this approach a try. It means you don't have to keep any additional state, which was a concern you mentioned earlier. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSView mouseDown truncated coordinates
On 23.02.12 21:55, Quincey Morris wrote: Ah, it's clear now. But I still think your theory is flawed. You can't assume that the physical act of pressing the mouse button doesn't change the reading (that is, doesn't possibly move the mouse slightly). I don't think that the rounding in mouseDown has anything to do with it. All we know is that currently, the mouse can move during the act of pressing down without producing a new mouseMoved, whereas previously it didn't behave like that -- or, not often enough to notice. I agree, but... Incidentally, I have some event-related code that's evolved for years over a series of different apps, and I noticed recently that in its last evolution a couple of years ago, I apparently arranged for all of the common events (mouseEntered, mouseExited, mouseMoved, mouseDown, mouseUp, mouseDragged, keyDown and keyUp) to always call cursorUpdate before doing whatever else they do. That allowed me to consolidate the hover-highlight-detection in one place (cursorUpdate), and gave consistency to the highlighting in cases exactly like the one you're describing. I think I do exactly the same thing, unless I missunderstand what cursorUpdate does for you, namely (1) detect which item to highlight, (2) which to lowlight, (3) which to leave alone and (4) do all that. All in a central place. Mouse movement highlighting must happen when the mouse moves. At that time, only the mouse move coordinates are known. They correspond with what happens on the screen, so highlighting works as expected. Now a mouse-down comes along with different coordinates. That change in coordinates is not reflected visually on screen (no cursor movement, no highlight changes). It leads to other objects than the one highlighted one being manipulated. Really confusing to the end user. Regards Markus PS: None of your or my replies seem to make it through to the list although both you an I cc the list. Not sure why that is. -- __ Markus Spoettl ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSView mouseDown truncated coordinates
On Nov 25, 2011, at 6:17 PM, Steven Spencer wrote: I'm using a NSTrackingArea in a view to receive mouseMoved events. The cursor location in the mouseMoved and mouseDragged events have non-integer coordinates (as expected). e.g. x:140.601562 y:128.082031 However, the mouseDown and mouseUp events always produce truncated coordinates. e.g. x:140.00 y:128.00 This causes inaccuracy with hit testing between mouseMoved and mouseDown. All the mouse events use the same code to convert the point for the view : NSPoint location = [self convertPoint:[theEvent locationInWindow] fromView:nil]; On Nov 26, 2011, at 10:58 AM, Ken Thomases wrote: We've seen this, too. It started happening with Lion. I filed a bug report on this. Bug 9639143 on 20-Jun-2011. I also recently filed a technical support incident asking for resolution or a workaround. The request is pending. My observations are as follows: -[NSEvent locationInWindow] can produce non-integral values in Lion with a mouse. This did not happen in previous versions of the OS. This is a Lion regression. Using floor, ceil, or round on the returned value does not work because the value can be off by as much as +-1.0. The amount of error in the value returned can be somewhat random. It is not constant. -[NSWindow mouseLocationOutsideOfEventStream] also produces non-integral values in Lion with a mouse. MacOS X 10.1 Application Framework release notes states that -[NSEvent locationInWindow] may now return NSPoints with non-integral coordinates to represent sub-pixel precision generated by some input devices, for instance tablets. However I do not think that this is relevant because this issue happens with a mouse not a tablet. This issue is not a sub-pixel precision issue. If it was then simple rounding or the like would fix it. http://developer.apple.com/library/mac/#releasenotes/Cocoa/AppKitOlderNotes As a side note, I have also noticed that the mouse tracking speed and or acceleration curve is different (think worse) in Lion when using the same system preferences as in Snow Leopard. In closing it is great to know that others are also having difficulty with this issue. :) --Richard ___ 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: NSView mouseDown truncated coordinates
BTW, I was informed off-list that an app can also receive higher-precision coordinates in mouse events if the user is working with a tablet (Wacom etc.) This could obviously be useful in paint apps for antialiasing brushstrokes. —Jens ___ 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: NSView mouseDown truncated coordinates
Many thanks for your replies, Jens and Ken. I use the mouseMoved event to set the mouse cursor according to whether a NSBezierPath instance contains the mouse point [pathInstance containsPoint:], to indicate whether the path can be moved. There is no scale transformation on the view. On the boundary of the path, the mouseMoved and the mouseDown events disagree whether the mouse point is contained by the path even though the mouse pointer has not moved. e.g. mouseMoved says the point is outside the path, whereas mouseDown says it is inside the path. The cursor indication gives a false impression that the path cannot be moved when it actually can be moved. The disagreement is caused by the fractional part of the location coordinates in mouseMoved and the integral coordinates in mouseDown. I thought that high precision mouse/trackpad movement was possible and that the location could be adjusted to match the screen resolution using NSView centerScanRect. However, centerScanRect (arithmetically) rounds the location to the nearest pixel whereas mouseDown has truncated the location. It looks like I may have to truncate the coordinates in mouseMoved, to match what mouseDown does. I noticed that NSWindow mouseLocationOutsideOfEventStream does produce the non-integral coordinates when called from mouseDown, though that may not be the right direction to go. Steven ___ 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: NSView mouseDown truncated coordinates
On Nov 25, 2011, at 5:17 PM, Steven Spencer wrote: I'm using a NSTrackingArea in a view to receive mouseMoved events. The cursor location in the mouseMoved and mouseDragged events have non-integer coordinates (as expected). e.g. x:140.601562 y:128.082031 Weird; I don’t think I’ve seen non-integer mouse coords before. Does your view have a scale transformation on it? However, the mouseDown and mouseUp events always produce truncated coordinates. e.g. x:140.00 y:128.00 This causes inaccuracy with hit testing between mouseMoved and mouseDown. You might need to truncate the moved/dragged coords too, then, just for consistency. I don’t think the OS tracks the mouse position at a resolution higher than screen pixels anyway. —Jens___ 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: NSView mouseDown truncated coordinates
On Nov 25, 2011, at 7:17 PM, Steven Spencer wrote: I'm using a NSTrackingArea in a view to receive mouseMoved events. The cursor location in the mouseMoved and mouseDragged events have non-integer coordinates (as expected). e.g. x:140.601562 y:128.082031 However, the mouseDown and mouseUp events always produce truncated coordinates. e.g. x:140.00 y:128.00 We've seen this, too. It started happening with Lion. I also don't think it's quite as expected. Among other things, the fractional part is generally constant for long periods, even while the integral part changes. That is, you're not seeing high-precision movement, just non-integral coordinates. This causes inaccuracy with hit testing between mouseMoved and mouseDown. What is the correct way to obtain coordinates that are consistent across all the mouse events ? As Jens suggested, you may wish to truncate the mouseMoved coordinates yourself. Or, you may need to use floor(). You should check what happens for a display to the left and/or above the primary, which would have negative coordinates. On the other hand, how is it causing inaccuracy? How are you using the coordinates such that the difference is significant. You generally shouldn't use '==' to compare floating point numbers in any case, for example. Regards, Ken ___ 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
NSView mouseDown truncated coordinates
Hi, I'm using a NSTrackingArea in a view to receive mouseMoved events. The cursor location in the mouseMoved and mouseDragged events have non-integer coordinates (as expected). e.g. x:140.601562 y:128.082031 However, the mouseDown and mouseUp events always produce truncated coordinates. e.g. x:140.00 y:128.00 This causes inaccuracy with hit testing between mouseMoved and mouseDown. All the mouse events use the same code to convert the point for the view : NSPoint location = [self convertPoint:[theEvent locationInWindow] fromView:nil]; Logged as e.g. NSLog(@moved x:%f y:%f, location.x, location.y); What is the correct way to obtain coordinates that are consistent across all the mouse events ? Thanks. Steven (Xcode 4.2.1 64bit LLVM 3.0 ARC) ___ 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
