Re: Mouse Lock

On Mon, Aug 29, 2011 at 2:29 AM, Vincent Scheib <scheib@google.com> wrote:

> I believe first developers seek a specifiable solution that will provide a
> consistent application experience on all platforms and API implementations.
>

Yes, the "raw input" method provides this.  (I don't like calling it that,
since it's not necessarily anything of the sort and it suggests that it's
lower level than it is, but I don't have another name off-hand to
distinguish these.)

 Finally, I believe that it is worthwhile to consider adding some rawer form
> of the input data if possible in a v2 implementation and or spec.
>

The "raw input" implementation requires a different interface.  What you
suggest would require implementing and supporting two completely different
approaches to delta input.  This seems shortsighted.

>
Movement values will stop when the cursor hits a screen edge.
>

This defeats the purpose.

I'm deferring consideration for higher resolution mice data and sampling
> frequency to a future version of this specification. This was discussed some
> in "Provide mouse deltas without hiding the cursor, alternatively provide a
> bounding rectangle for mouse". But a summary of my position is that:
> - Specification is difficult and may not be possible.
> - Implementation is more complex and doesn't seem justified yet.
>

As I pointed out before, both specification and implementation is simpler; a
laundry list of complexities go away.

- Graceful addition of more 'raw' data and higher sampling frequencies is
> possible. I'm not saying "We shouldn't implement raw data", but I am saying
> we should defer it.
>

I don't believe "graceful addition" is possible; an entirely separate
interface, using a separate event, would be necessary.  As a result, if this
approach is implemented, it'd be much less likely that the other would ever
happen.  Half-solutions have a tendency to prevent the creation of a full
solution, even when it's claimed beforehand that it's only being "deferred".

This was vaguely suggested in that no one made a clear proposal of what
> separate events would look like. click, down, and up events are needed. The
> current events use the MouseEvent type. I believe that for the same reason
> mousedown includes more context than just "the mouse button was pressed"
> that the mouse lock equivalent would too. Thus, the mouse lock version of
> click, down, and up events should contain .movementX/Y data.
>

This doesn't make sense to me.  Movement is unrelated to clicks.  There's no
need to have special "locked versions" for these events; there's no movement
data associated with a click.  If they had "movement" attributes, they would
always be zero.


If you want a concrete proposal, I'd start with something like this:

> When a delta input device is moved, fire an event named "mousedelta",
which bubbles and is cancelable, and uses the MouseDeltaEvent interface, at
the Window object.  The deltaX attribute must be set to the horizontal
distance moved, with positive values indicating motion to the right.  The
deltaY attribute must be set to the vertical distance moved, with positive
values indicating motion downwards. A delta value of 400 must indicate a
movement of one inch.
>
> interface MouseDeltaEvent : Event {
>   readonly attribute float deltaX;
>   readonly attribute float deltaY;
> };

The value of 400 DPI is suggested because, according to [1], that's the most
common resolution for mice.  Implementations scale values to that resolution
if necessary.  The interface uses floats, to support arbitrary-resolution
input.

[1] http://msdn.microsoft.com/en-us/library/ee418864%28v=vs.85%29.aspx

-- 
Glenn Maynard