[Development] some questions about QtGamePad

[Matthew Woehlke]

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