Duane, you wrote:
Hmm... not sure about that. It is possible that someone might want the cursorPoint and the mousePoint to be different things. If we interpret the mousePoint to be the position of the physical mouse,
I can't see why one wants to know the position of the mouse on the mouse pad.
and the cursorPoint to be the position of the indicator on the screen, then gridding is an example where they might be decoupled.
I would prefer griddedCursorPoint then.
There are some actual examples of the this is a couple of commercial Mac draw/paint applications, and MacApp explicitly supported this idea. When gridding was on, the cursor jumped between grid points to be near the mouse. This gave better feedback to the user about what would happen when the button was pressed, since without it it's not as clear which grid point would be chosen.
The Morphic developers have chosen to do this at the Morphic side. I agree that griddedCursorPoint might be a worthwhile addition to InputSensor. OTOH, one could add a method to Point as in:
sensor cursorPoint griddedTo: aPoint
where aPoint is a normalized point which defines the grid in both x and y direction.
All I'm saying is that there are only 11 senders of mousePoint (like Celeste). I would like those to use cursorPoint and then remove mousePoint. 226 clients of cursorPoint get 3 message sends to obtain the cursor point:
cursorPoint sends mousePoint send primMousePt which is primitive.
I want to keep primMousePt (it's categorized private anyway) and recode cursorPoint to use the primitive.
That means that 226 clients suddenly have a very short message path for obtaining the cursor point:
Cheers, Reinier.
squeak-dev@lists.squeakfoundation.org