On 2016-02-16 12:08, Nichols Andy wrote: > I’m sorry if my mail came off as obstructionist as it was not intended in > this way.
Not at all :-). (Opinionated, perhaps, but I wouldn't say "obstructionist". I have no philosophical problem with strongly held opinions, being one who often holds strong opinions myself.) If the previous message seemed... "agitated", that was directed at Curtis, not you. > 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. And... what's wrong with that? :-) I happen to think that SDL is a very nice API, and I would *love* to see something similar (but with signals, of course!) in Qt. Again, while I don't think *I* would ever use the limited QGamepad API, my biggest objection is that you *need* the lower level API in order to implement QGamepad (which means you've *implemented* said lower level API), but you haven't exposed it. So, if QGamepad isn't a perfect fit for me, I have to implement the lower level abstraction myself, when I could just use yours if only it was made public. > 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. This is another point where I find I can't agree. There are two major use cases for handling joystick input. Either I allow the user to map the controls the way they want (i.e. I have such an input mapper), or I require the user to use a particular controller and mapping, in which case I just hard-code the mapping anyway and don't need an abstraction layer over the raw hardware. It looks to me like QGamepad is trying to create a third case that combines the worst aspects of both options, where there is some ability for the user to "fix" a controller with the right number of inputs but "wrong" labeling of those inputs so that it can be used with a program that hard-codes what does what. I'd be much more interested in going that next little bit further and just providing a full blown input configuration system in a library. > 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): ...and I'll point out that, if this isn't suitable, you can use the SDL Joystick API :-). If there *was* a Qt joystick API, then having a restricted API built on top of it wouldn't bother me nearly so much, as I'd just ignore it. > So hopefully this add’s a bit more rational. Sure... and again, it's not so much that I'm opposed to having a high level abstraction for a restricted use case (if that use case is sufficiently common), it's that I dislike not making the less abstracted functionality available for the cases where the higher abstraction doesn't match, and/or users need to be able to fiddle with things "under the hood". Better (at least, more Qt-relevant) analogy: it's as if we had QTreeWidget but not QTreeView or QAbstractItemModel. -- Matthew _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development