W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Re: [Gamepad] Liveness of Gamepad objects

From: Glenn Maynard <glenn@zewt.org>
Date: Wed, 30 Apr 2014 10:16:40 -0500
Message-ID: <CABirCh-=PAQVx1ULJdacb4i3=veqHUHkefo+XfVthEOM+Kskyg@mail.gmail.com>
To: Ted Mielczarek <ted@mozilla.com>
Cc: public-webapps WG <public-webapps@w3.org>
On Wed, Apr 30, 2014 at 5:58 AM, Ted Mielczarek <ted@mozilla.com> wrote:

> Yes, it's true. In any event, this is going a bit afield. We're not going
> to spec events for the first version of the spec.
>

Examining the features that each design would make easier or harder isn't
afield.

On Wed, Apr 30, 2014 at 6:11 AM, Ted Mielczarek <ted@mozilla.com> wrote:

> My only reservation is that if Gamepad becomes a snapshot instead of a
> live object, it feels weird to suggest adding output methods to it (like
> adding vibration support). Perhaps I'm overthinking it, though.
>

I cut out a comment about that for length, actually.  It would be better to
have separate objects for the gamepad itself and where output methods live,
and another interface holding a snapshot of an input state.  Then, you'd
just call gamepad.getState() to read the state for that device.  It's also
a natural place for an event interface to live, and for input state that
doesn't change, like the device's ID.

I definitely wouldn't make Gamepad live just to avoid doing that, though.
 It could always be added later, by adding a GamepadDevice interface, eg:

gamepadDevices = navigator.getGamepadDevices();
gamepad = gamepads[0];
state = gamepad.getState();

equivalent to navigator.getGamepads()[0].

--
Glenn Maynard
Received on Wednesday, 30 April 2014 15:17:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC