Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Be able to use both hands #17

Open
iangilman opened this issue May 8, 2020 · 5 comments
Open

Be able to use both hands #17

iangilman opened this issue May 8, 2020 · 5 comments

Comments

@iangilman
Copy link

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!

@arthurmougin
Copy link

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 !

@dmarcos
Copy link
Member

dmarcos commented Dec 15, 2020

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

@levexis
Copy link

levexis commented Dec 24, 2020

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
Copy link

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
Copy link
Author

iangilman commented Dec 24, 2020

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants