Forum Discussion
[FEATURE REQUEST] Make a system-level virtual keyboard available within Oculus Utilities!
Have a look at this old thread from 2015 for some context.
It seems a bit absurd to me for Oculus to have a bunch of sexy, cylindrically-rendered virtual keyboards at use in their own apps and then not provide one in Oculus Utilities to fulfill the needs of hardware keyboard input into Unity's stock UI components that respond to text input. Something like if you were using the Oculus SDK in XR Settings, it would come up when selecting any UI Selectable that responds to MobileKeyboard/TouchScreenKeyboard class stuff.
Right now, if you use an InputField and call InputField.ActivateInputField() on either a Go or a Gear VR, it tries to bring up an Android keyboard! You can clearly observe this on a GearVR phone in developer mode (you can actually swipe up and start using the keyboard), and on a Go I can even see what I think is a collapsed Android keyboard attempt to come up on the bottom of my viewport before going away. This seems like a serious lapse in implementation of the Go's Android runtime organized around that point.
Lots of Assets exist on the Asset Store for doing VR text input. I'm using a hacked version of the Weelco one, myself. But they all have come up with their own kind of tools for internally managing their output string and having their own kind of InputField equivalent. If Oculus just provided some of the basic functional ones at the SDK level (QWERTY, Numpad, etc. all the ones that are outlined in MobileKeyboard), we could get so much for free just by piggybacking off of the Unity's existing tools. A blinking caret, mid-string editing, drag highlighting and editing, enforced character limits and password masking, etc. etc. etc.
It seems a bit absurd to me for Oculus to have a bunch of sexy, cylindrically-rendered virtual keyboards at use in their own apps and then not provide one in Oculus Utilities to fulfill the needs of hardware keyboard input into Unity's stock UI components that respond to text input. Something like if you were using the Oculus SDK in XR Settings, it would come up when selecting any UI Selectable that responds to MobileKeyboard/TouchScreenKeyboard class stuff.
Right now, if you use an InputField and call InputField.ActivateInputField() on either a Go or a Gear VR, it tries to bring up an Android keyboard! You can clearly observe this on a GearVR phone in developer mode (you can actually swipe up and start using the keyboard), and on a Go I can even see what I think is a collapsed Android keyboard attempt to come up on the bottom of my viewport before going away. This seems like a serious lapse in implementation of the Go's Android runtime organized around that point.
Lots of Assets exist on the Asset Store for doing VR text input. I'm using a hacked version of the Weelco one, myself. But they all have come up with their own kind of tools for internally managing their output string and having their own kind of InputField equivalent. If Oculus just provided some of the basic functional ones at the SDK level (QWERTY, Numpad, etc. all the ones that are outlined in MobileKeyboard), we could get so much for free just by piggybacking off of the Unity's existing tools. A blinking caret, mid-string editing, drag highlighting and editing, enforced character limits and password masking, etc. etc. etc.
2 Replies
Replies have been turned off for this discussion
- This is a really great suggestion, and to be honest I'm shocked Oculus hasn't already got one.
(SteamVR does!)
The idea that developers should each implement our own VR keyboard instead of using 1 constantly improving one that follows the guidelines is silly.
imperativity said:
Hi,
Thanks for the feedback here. At this time we don't have this functionality but I will pass this along to our internal teams responsible for guiding future development for Go.
Cool, thank you! It seems like a rather showstopper-level oversight that I have the ability to pull up an unusable Android keyboard using stock Unity UI Components on the Go. I should think this would necessitate its being executed.
