I have a “remote” desktop type thing we do, you can look up my linkedin if you are curious, but basically I have the need to send keyboard keys as if they were really typed in. BUT the tool we currently use is Java and has a few downsides. Some key combinations don’t work very cleanly in it. Upsides are it’s OS portable which is super critical as we need a MacOS, Ubuntu/Centos and Windows runnable tool. Yes I have to map Apple-Mac keyboards to Windows, and back, but that’s my problem. Anyone got a keyboard emulator tool that rocks and is cross platform for desktops?
Hi @conrad.braam : Just curious that you got the solution / workaround for above.
I dont have direct answer to problem but I wrote some scripts etc on window to login and for linux using cli mode like ssh .
2 Likes
I’m coming back to this topic again it seems. Today my context is really “bluetooth” however. But since it’s my question I can change it as I like I guess. For our current mobile app, we have always wanted Bluetooth keyboard tests to also test with a real keyboard. Now anyone who knows what an Arduino or what an ESP32 is, will know that actually, this is a solvable thing. The beauty is that a bluetooth keyboard emulator would work for platforms with BT keyboards as well as platforms with normal wired keyboards if all you do is plug in a BT dongle to “turn” it into a wired keyboard.
But right now I’m instead, of building a cool little Arduino project, going to rather outline why and what test cases I want to cover for my own use. So that I can build up a better shared picture of the risks anyone might face if not covering risk by automating the test. And focus less on how hard it will be to get the test built.
- Bluetooth/HW keyboard testing a mobile app in Cloud-provided mobile test environments is as far I know, not possible. So I’m expecting to find it valuable to test that gap, manually or automatically.
- When you tend to use a HW keyboard, it’s usually to make typing on a small factor device easier when testing. I’m thus loosing the coverage on small factor devices when the touch keyboard sometimes will obscure content. This has the downside that we don’t test HW keyboard workflows on a tablet, because it’s easy to type on the tablet anyway.
- Keyboard input focus issues - (Example: Windows and macOS have an annoying habit of popping a dialog up asking you to input something, but not setting focus to the input field.) Automated test scripts have a nasty habit of working around input focus default control bugs. I can perhaps find places where the test code works around an unexpected default input focus being wrong?