Be able to use both hands about aframe-super-keyboard

[dmarcos]

@arthurmougin I agree it would be useful to use two hands. We have to juggle other priorities and we have no time to address this at the moment. We will be more than happy to take PRs if you have bandwidth. Thanks folks.

[arthurmougin]

Same request, it is needed for VR use.
@dmarcos @ngokevin can you please have a look to this issue ?
Thank you in advance for your time !

[levexis]

Depending on your use case you can put the keyboard on the left controller, I find moving the keyboard easier / more natural...

<a-entity id="myRig">
       <a-entity id="leftHand" laser-controls="hand: left">
           <a-entity id="keyboard" super-keyboard="hand: #rightHand; imagePath:../../dist/" position="0 0.1 0" rotation="-90 0 0" scale="0.2 0.2 0.2"></a-entity>
       </a-entity>
       <a-entity id="rightHand" laser-controls="hand: right"></a-entity>
       <a-entity id="head" camera wasd-controls look-controls position="0 1.6 0"></a-entity>
</a-entity>

[arthurmougin]

Hoo not bad indeed! I am concern about accessibility though. It require to have 2 tracked controllers while most 3dof VR headsets don't have that :/
Plus, I am also focused on ergonomic and productivity and requiring only one typing hand make it slow..

[iangilman]

I don't have the time to make this change, but here are some thoughts on how to do it, if you want to, @arthurmougin:

The main reason it only supports a single controller is that the keyHover property is a single value, rather than an array. I would change it to an array (or add a second property called something like otherKeyHover if the maintainers (e.g. @dmarcos & @ngokevin) feel it's important to maintain backward compatibility), and go throughout the code to change its handling to support multiple hovers.

You then need to update the click handler to be able to differentiate between which controller got clicked. I forget how to do that, but it should be standard A-frame stuff.

You also need to update the hand attribute, hand property, and raycaster property to support multiples. At least that's what I'm seeing, looking at the code. There may be more. At any rate, by starting with keyHover and working your way up, you've got a clear path of what to do.

Because there are a number of properties that need to go from singular to multiple, it might make sense to make a new kind of object that has all of those properties, and create an array to store multiple copies, one for each controller. That would be a bigger architecture change, though, and therefore would affect any existing users of this library that are expecting to be able to manipulate the internals. That said, none of the internals seem to be part of the external API, so people shouldn't be relying on that anyway. Ultimately that's a decision for the maintainers; hopefully they can chime in on where they stand there.

I hope this is helpful!