Re: [w3c/gamepad] Move vibrationActuator to the main spec (PR #190)

@cabanier commented on this pull request.



> +          Promise<boolean> pulse(double value, double duration);
+        };
+      </pre>
+      <dt>
+        <dfn>pulse()</dfn> method
+      </dt>
+      <dd>
+        <p>
+          <code>pulse()</code> applies a <var>value</var> to the actuator for
+          <var>duration</var> milliseconds. The <var>value</var> passed to
+          <code>pulse()</code> is clamped to limits defined by the actuator
+          type. The returned Promise will resolve <code>true</code> once the
+          pulse has completed.
+        </p>
+        <p>
+          Repeated calls to <code>pulse()</code> override the previous

> With that framing in mind, the fact that this resolves to a boolean rather than void tells me that the boolean was intended to communicate information. It feels to my like the intent was "resolve when the requested pulse is finished, with true if it was allowed to complete and false if it was pre-empted." I wouldn't expect it to reject unless perhaps the pulse simply couldn't be rendered by the device haptics at all? Even then it seems possibly more ergonomic to never reject.
> 
> Whether or not that's what the Meta implementation does is an entirely different story.

I checked the Quest implementation and it's running `pulse` through the same codepath as `playEffect` after clamping.
Looking through the code, I can't see where this would return false except for cases where the controller doesn't have haptics (ie hands)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/pull/190#discussion_r1423831328
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/gamepad/pull/190/review/1777211107@github.com>