MouseInput should have a position

[JMS55]

A common case is to get the location on screen a user clicks. The way to do that currently is to create a variable that stores the cursor location, which is updated whenever CursorMoved is received. Then, when a MouseInput event is received, you use whatever that variable is currently set to. I think it would be useful for winit to do this internally, so that the MouseInput event could store a position, making it easier for the user. winit should also update the variable whenever Window::set_cursor_position() is called.

[elinorbgr]

It may be important to keep in mind that there are literally edge cases to take into account: when the cursor reaches the border of the monitor, MouseInput events can keep being generated while the actual location of the cursor does not change.

More generally, there is the question of the behavior of such a field when the cursor is outside of the window, as there will be platform dependent quirks.

[JMS55]

Good points. Another problem I thought of is since it uses the location from the previous event poll, if your program is lagging badly, than the mouse will have moved a big distance relative to the previous poll, so it will seem like your input is lagging even more. Not sure if that's how it works, but it seems logical.

[aloucks]

This would convolute the the MouseInput event.

There is already WindowEvent::CursorMoved (in-window only and possibly accelerated) and DeviceEvent::MouseMotion (tracks raw movement even when the cursor leaves the window and should not be accelerated). The former is for emulating a cursor and the later is better suited for camera control.

You would need to pick one of these to attach to MouseInput and either option would be wrong because there are use cases for both. The mouse position should remain separate from the button input.

[cedric-h]

This takes like 25 lines of code for the user to implement and doesn't fall within the scope of things that winit sets out to do. This feels opinionated; it's really up to the user to decide if they want to use the location data when the mouse is clicked. The API, as it is now, reflects that.

[JMS55]

I do not believe it convolutes MouseInput, in my opinion it is a fairly basic task and it would help for winit to at least show the user how to track MouseInput locations. If that's in the form of an example instead of a MouseInput field, that's alright, but I think winit would benefit from adding a field. The fact that there are edge cases that need to be accounted for just gives weight to including it in winit and preventing the user from messing it up.

In terms of technical feasibility and api choices:

• I admit I don't know the details of MouseInput that well. Can MouseInput events be generated from clicks outside the window?
• CursorMoved vs MouseMotion: If MouseInput's are only generated inside the window, than it makes sense to only use CursorMoved
• If MouseInput's can be generated outside the window, than it would be up for discussion. I don't know the difference between accelerated vs non accelerated that well

@vberger what do you mean by "MouseInput events can keep being generated while the actual location of the cursor does not change."? I assume MouseInput's are generated due to clicks, in which case if the position dosen't change, that dosen't matter, then you just have many clicks in the same place.

[elinorbgr]

Sorry, I was not formulating this correctly, forget about this part.

The thing is, currently winit strives to have a scope small enough to be reasonably maintainable. As such, anything that can be easily implemented outside of winit will, in general not be implemented in winit unless it can be justified that the implementation would be significantly simpler if it lived in winit.

This really does not seem to be the case here. However I agree it'd be worth adding an example showcasing the proper way to track cursor location.

[icefoxen]

I agree with the original argument that it is quite rare to want to get a mouse input event without having the position associated with it. Same with TouchpadPressure, really. Given that it takes 25 lines of code to do, I'd prefer that we do the 25 lines once, in winit, rather than everyone having their own. And given that we already have WindowEvent vs. DeviceEvent splits, each with their own motion and button types, the answer to the question of "which type to do where" seems obvious.

I'll make a demo PR for discussion if people want.