Be able to use both hands

Thank you for building this lovely keyboard!

In the VR experience I’m building, I allow the user to use both hands interchangeably (or together). I’d love to be able to extend that to the keyboard, allowing both hands to type, instead of having to pick one of the hands.

Is this possible with this keyboard? It doesn’t appear to be… I tried this attribute:

super-keyboard="hand: .left-hand, .right-hand;"

… but it only accepted hovers from the left hand.

Looking at the code I suppose it would need to be updated to support two simultaneous hovers, and when clicks happen to know which hand do the clicking, so it doesn’t seem like a trivial change.

Anyway, seems like it would be nice!

[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.

[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!