Closed fernandojsg closed 6 years ago
The important bit is that the user (via some configuration interface), not the developer, will be the one configuring/connecting these "middleware" components as they relate to the specific way that user (or the developer creating a default mapping) wants to map the real hardware input to the application specific actions.
Ideally since these things don't actually care about aframe in any way at the moment (they are just event transformers essentially) these could be done in a non aframe specific way. If you imagined the stuff tracked-controllers does getting folded into input mappings someday, that package would be a very useful even outside of the aframe community.
That said aframe components do give us some nice features like the parsing/handling of options.
@netpro2k yep. I've implemented a POC with longpress and doubletouch/press without doing anything aframe specific but just a custom modifier. I agree that this should be something that the user could modify in the future, things like do I want double tap or maybe triple-tap, how long to wait between one tap and the second, and so on. From now I'll try to implement some of the gestures defined and I'll share in a PR so we could discuss about the best way to define them.
Instead of creating an aframe component like @netpro2k 's https://github.com/mozilla/mr-social-client/blob/master/src/components/axis-dpad.js we should define a way to register these component directly on the
input-mapping
system so the user doesn't need to care about dealing with them. These components could help define behaviours like: