We noticed that you added Windows Virtual Keyboard support in your //ue5/main stream.
Is it complete?
Do you have any recommendation about how to use it with FSlateEditableTextLayout and FPlatformApplicationMisc::RequiresVirtualKeyboard?
We have our own internal implementation (similar to yours) and we also changed “RequiresVirtualKeyboard” to return true on Handheld devices: what should the FSlateEditableTextLayout behaviour be in case “RequiresVirtualKeyboard” succeeds and CoreInputView::TryShow(Gamepad) fails?
Is it better to test for anything else in “RequiresVirtualKeyboard”? (such as testing for CoreInputView::IsKindSupported(Gamepad) instead of Handheld mode)
Do you have any other hint to correctly manage such keyboard with Slate?
Do you recommend to use this keyboard with WinGDK too instead of using the built-in GDK keyboard?
Regards
Hi,
The Windows Virtual Keyboard support is still extremely experimental, and was only just added as a stopgap to resolve some blocking issues we ran into on Windows-based handheld devices. You can give it a try by enabling the plugin and using the slate.testvirtualkeyboard console command, though note that it requires a recent Windows 11 update (26100.5061) so you may need to use winver to verify that you’re up to date or manually download the update. Our QA hasn’t verified it yet, so its tough to say how stable it is.
If you have a working implementation now, I’d recommend holding off until this ships with an engine release since that will at least guarantee it’s gone through a bit more rigorous testing. Our approach here was to avoid changing RequiresVirtualKeyboard (since the plugin may be disabled or not supported based on Windows version) and to instead have the plugin register itself as a modular feature and inject it’s own platform text field so that no engine changes are needed. Generally speaking, RequiresVirtualKeyboard just determines whether or not we should attempt to summon one; if it fails, the expected result would be to do nothing.
Best,
Cody
Thank you for the detailed explanation.
We changed RequiresVirtualKeyboard because, from our understandings, it seems that FSlateEditableTextLayout can automatically call ShowVirtualKeyboard only if RequiresVirtualKeyboard succeeds.
So, to avoid changing the engine, do you propose to configure (for example) “bAllowVirtualKeyboard=true” through (readonly) cvar configuration when the plugin is enabled?
Or is it better to directly call “SlateApplication::ShowVirtualKeyboard” when needed, bypassing the FSlateEditableTextLayout automation, so it could be opened also when RequiresVirtualKeyboard is configured to return “false”?
Hi - what CL was this support added, I’d like to take a look and merge it into our code base or even just as a reference, as we now have issues w/ virtual keyboard and handheld devices etc on our game too… thanks!
Hi,
You can find those changes at CL#44931610.
Ah, I see now. The current changes will override ShowVirtualKeyboard, but don’t do anything to ensure it will be called. The engineer who is working on the feature is currently on sabbatical, so it’s likely currently in an incomplete state. Since things are very much still in flux and some of this could be refactored, I think your safest option would be to use the AllowVirtualKeyboard cvar for now to forcibly override RequiresVirtualKeyboard on platforms where you want it. Ultimately, we may end up implementing a FWindowsPlatformApplicationMisc::RequiresVirtualKeyboard to be a bit smarter about determining whether the device is a handheld, but that’s a bit speculative so a less intrusive workaround might help you avoid some integration headaches down the line.
Ok, thank you very much for these additional details.
We’ll try to minimize our changes in that area, in order to simplify next integrations from UE.
Best regards.