Mouse and Pointer Events

[hobnob]

This is a breaking change, and I'm not sure I'm happy about it, so a second (or third) pair of eyes would be very welcome.
This change adds a majority of the properties found in both Mouse Events and Pointer Events. The upshot is that in doing so a simple Click(position) match now becomes Click(position, _, _, _, _, _, _, _), however we now have a wealth of new information about the event itself. some key changes are:

Key Down Properties

Various helper properties (isAltKeyDown etc.) to check if a key was held down during the event. The difference here compared to, say, keeping a track of key up/down events within Indigo, is that if the button is held down outside of the scope of the game (such as in another window) this property will still be correct, whereas Indigo will think the button is not held down.

Buttons Properties

The buttons proeprty was previously just on Pointer events, but is also available for the Mouse. As such, this property has now been moved to the Mouse event and updated to be a Batch of MouseButton

Mouse Enter/Leave

We already have a Pointer Enter/Leave - we now have the same for the mouse, which fixes #512

Tilting, Twisting, and Preassure

Pointer events have been updated with Tilt X/Y, Twist, and Preassure properties. More details on these can be found on the MDN docs. The main change from the docs here is that Twist and Tilt properties are in Radians not degrees.

Limited Firing of Events

Previously we fired mouse events every time we registered a pointer event. We now only do this if the pointer type is Mouse.

[davesmith00000]

Broadly looks good. Going to have another look with fresh eyes.

I'm mostly concerned about the pointerType == PointerType.Mouse filters. Another person was last working on this stuff and I'd been convinced that we should be moving to Pointer events rather than mouse since they were more broadly applicable and allowed us to support additional input types. This looks like we're filtering them out again, but I could be wrong, what's the deal?

[davesmith00000]

I'm not sure we want that do we? I was under the impression that pointer events were also used for things like touch input?

[hobnob]

Yes they are, but we should really only fire things like MouseDown if the pointer is actually a mouse. To be honest this is a deviation from the browser, which will fire a MouseDown even if what actually occured was a touch event. Happy to keep the more standard browser behaviour of course, I personally feel this is more 'correct', but there's an argument I think for both approaches

[hobnob]

I'm mostly concerned about the pointerType == PointerType.Mouse filters. Another person was last working on this stuff and I'd been convinced that we should be moving to Pointer events rather than mouse since they were more broadly applicable and allowed us to support additional input types. This looks like we're filtering them out again, but I could be wrong, what's the deal?

There's definitely an argument to be had here for removing mouse events altogether, especially as PointerEvents inherit from MouseEvents, so you're getting no additional information with regards to the Mouse. The difficulty then comes later if you want to deal with Touch. TouchEvents (as fired by touchStart etc) have additional information about which Touches changed and where they started but don't inherit from PointerEvents. The question then becomes do we just ignore this and continue only supporting Pointer, or do we also support Touch, and in that case shouldn't we also support Mouse for completeness? For now, I think we should carry on supporting the mouse, and if we filter on the pointer type then that means the event itself can be used as a differentiator rather than having to do a match based on pointer type... but I could be wrong, it could be that people would prefer to filter on the pointer type rather than the event itself.

[davesmith00000]

Right, I'm with you now, thanks for the explanation. 👍

[davesmith00000]

LGTM, thanks @hobnob!