I’m using Keyman Developer 13.0.115.0 on Windows to make a touch keyboard that I have been testing on my iPad Pro (2nd Gen) running iOS 14.2.
I have been trying to add a TAB key to the touch layout. It is used in the US English keyboard on iOS and I’d like to keep close to that for familiarity, and having a TAB key can be useful.
I add the key as a “Special” key, with the code “K_TAB” and the text Tab. It looks great. However, it does nothing. When pressed, no tab appears. I’ve tried changing “K_TAB” to “U_0009”, but this is rejected as an illegal key code by the compiler.
Is there some way to get a functional TAB key in touch layouts? I’ve looked through the documentation and can’t find anything to suggest another way of doing it, or to say it is not permitted.
This worked well, but the addition of that rule seems to make my keyboard too complex to view in design view in Keyman Developer 13.0.115.0.
This is an expected behavior in Keyman Developer. The design view on Layout tab will only show simple layout. Since what you are doing is out of the normal, Keyman Developer considers this as complex and expects you to know exactly what you are doing.
For a complex keyboard, you can choose to enable OSK and fill from layout to see how the keyboard looks on macOS, Windows and keymanweb.
The tab key is a little interesting: it is used in most cases to move between text fields, and only a few apps really support the tab character within a document (e.g. Google Docs, and other document-style editors).
I would have expected this to work. Conversely, while @Makara’s suggestion (adding a rule) works in some circumstances, it may also not work for switching form fields on all devices.
@joshua_horton do you have any idea why a special key with K_TAB identifier wouldn’t be working on iOS? @darcy, can you verify on Android?
Upon investigation, it’s because of K_TAB's overloading when dealing with DOM elements. Right now, the internal engine is still interpreting K_TAB as a DOM command, not as text output, despite being embedded. It’d take a bit of work to fix that; there’s currently no behavior-switch for K_TAB based on whether or not the internal engine is embedded. It doesn’t look too troublesome to fix for 14.0, at least.
While this is somewhat affected by a lot of the work we’ve done for 14.0… to the best of my knowledge, this should hold true for both 13.0 and 14.0.
I strongly suspect the key won’t work via touch on Android. Physical keystrokes (from an external keyboard) may not be affected, though.
Looks like we’ll need to delay this until 15.0 - we’ve noted some serious complications that would arise when trying to implement this properly, and we’re too late into beta to do this properly right now.
The linked Github thread details part of our discussion and analysis of the issues, though some aspects were handled through other channels.