Hi Matthew, I do appreciate the feedback and suggestions for the API as it is now. I’m sorry if my mail came off as obstructionist as it was not intended in this way. Since this is a Qt API I want it to be both useful and easy to use. I conceded that the current API is limited to the available buttons on an Xbox 360 Gamepad, as that was the intended API deliberately limited in scope as this leads to an easy to use, but definitely limited API. My fear is that a more expanded generic API would turn into what SDL Joystick is now. I think that kind of API is useful, but it mandates the use of an input mapper (like the one in the Qt3D Input Aspect) to be usable in any reasonable way. So I would prefer to keep the API limited as stated, but this is an open source project and the API isn’t nailed down yet so we can change things if it makes sense.
I would contrast this module to the SDL GameController API which does include button and axis mappings that match the established “Gamepad” devices (Xbox, Playstation, WiiU Pro Controller): http://wiki.libsdl.org/SDL_GameControllerAxis http://wiki.libsdl.org/SDL_GameControllerButton By using QtGamepad, the expectation is that your end users would be able to plug in a “Gamepad” and that would have roughly the same button/axis configuration. Any other device that was “gamepadish” might work, but with no expectation of support. For many PC games, Gamepads work automatically assuming the same configuration. For games/applications that would need to support a multitude of devices, like a flight simulator, it would be important to use an API like SDL Joystick which does provide all button/axis/hats and their respective properties, and then provide a mapping mechanism to map Buttons/Axes/hats to actions, (and maybe even make that configurable ;-) ). It may be that it makes sense to create a lower level API for generic input devices. It was previously mentioned before but this would be similar to the SDL Joystick API where an input device could be queried and it would enumerate it’s buttons and axis as well is properties. This would serve the need of solving the original problem mentioned by Pritam regarding additional control sticks on a flight controller. So hopefully this add’s a bit more rational. I don’t think what you are saying is wrong at all, I just though what you suggested was out of the current scope of the module. And it could be that other disagree with the scope of the QtGamepad module as well, and there is still time to change it. And as always, contributions are appreciated as well, so If you’re feeling motivated submit some possible API revisions to code-review and add me as a reviewer. Regards, Andy Nichols freenode: nezticle Also, the unfortunate reality is that Free Software contributors (and engineers in general) tend to be jerks. We don't *have time* to coddle everyone we talk to. Tell me about it ;-)
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
