Closed mattdm closed 8 months ago
Also I know from Discord chat that you weren't convinced that anyone would want this. If you'd prefer, thanks to your modular design, I can maintain this as a separate crate. But personally, I think it makes sense in general.
I'll update this this evening when I get a chance!
I don't think this change is worth the added complexity because the input plugin already has this abstraction. A user can disable the mouse or touch inputs via the input settings:
and send their own InputPress
events using whatever logic they require. The reason I created the InputPress
event was to decouple inputs from hardware, and to allow users to drive pointer presses with whatever their hearts desired. I was hoping to keep the input plugin as simple as possible, so users could immediately see they could rip it out and replace it.
I appreciate the contribution, but as it stands I'm pretty hesitant to add more complexity to an already large plugin that aspires to be upstreamed. 🙂
To your comment about the crate, I think that's a great idea. If you want to create a fully featured mouse input plugin, that would be super cool! I'm mostly concerned about managing complexity inside this plugin.
This adds a configurable map to InputPluginSettings. This allows for configuring Right, Left, and Middle buttons as determined by bevy, as well as Other buttons (by number). It does not extend picking to provide target mappings other than Primary, Secondary, and Middle. (That's future work!)
The abstraction here makes it easy for games to provide end-user configuration of the binding. I'm not set on this particular interface to changing it and can update the code for other ideas.
If this is accepted, my next step is to tackle the "other" buttons.