Use OSK with desktop option?
imaclmaca opened this issue · 17 comments
I can't figure out how to use the on-screen keyboard with the raspbian desktop - is this possible.
I tried matchbox-keyboard, which I have used with raspbian in the past, but it was rendered vastly too large and so only a few keys were visible at all (so was useless.)
Anyone else seen this? Is there a workaround?
A slight addition to the observation on using matchbox-keyboard with the desktop view (since the cutiepi OSK does not seem to be available there...)
The reason that matchbox is rendered much too large is because the cutiepi reports having two monitors adjacent to each other, as an extended desktop (the DSI and HDMI2) and that the total width is therefore something like 2500 pixels (800 for the DSI and the rest for the HMDI2 view.)
As a result the matchbox keyboard (which scales to fit the screen automatically) is rendered really huge and is thus useless... I think it is possible to tell matchbox not do do that, but I have not figured out how yet.
Hi @imaclmaca thank you for the report, we have a new nightly build which enabled virtual keyboard on PIXEL desktop for GTK and Qt application, this implementation reuses the same qtvirtualkeyboard package:
If you like to test, here's the download link:
file: image_2022-03-28-raspios-cutiepi.zip
download: https://drive.google.com/file/d/1l7YCtGOv36ABwo5QfTlVio3IW3FPSMnV/view
shasum: 5f94268991a389f1a89999dee997c188822a6123
OK - tried that; pretty much works, but...
- It automatically capitalises the first letter of each keyword I type, and I can not see how to stop it doing that. This makes it very awkward to use to enter terminal commands.
- The key presses are delivered to the shell "word by word" rather than "letter by letter" which is awkward for some use cases.
- There is no way to inject CTRL sequences, like CTRL-C in particular, which is awkward when I started a long process and then realised I'd typed the wrong options.
@imaclmaca thank you so much for the test.
For the first two things I agree with you, but that's the default qtvirtualkeyboard behavior -- I'll see if we can disable predictive text and word selection without changing too much of the code. For ctrl key that'll require a custom layout, I'll try to add that with a Qt.ControlModifier key event in the Terminal layout.
Note to self: will probably back-port this setting property from Qt6.1 to Qt5.15 to set default input method hints.
qt/qtvirtualkeyboard@e923b4f
@penk - update, after some more testing, I'm seeing an odd behaviour where, when I have my wireless keyboard attached, the OSK is blocking any keystrokes on the "real" keyboard being delivered to any GUI apps I have running.
But the "real" keyboard still goes to the terminal OK so it works fine, which is why I did not notice this before, I think.
In other news, I have pretty much given up on matchbox-keyboard and switched to using "onboard" instead, and TBH it seems to be working pretty well, actually - I should have tried it first, but I'd used matchbox before so... Lessons learned...
New build disabled the predictive texts:
File: image_2022-03-29-raspios-cutiepi.zip (1.2G)
Download: https://drive.google.com/file/d/10EqVsNsttJuwdjlf7Sw-FGzVXC4B5BOy/view
Sha1sum: 782c1b1e3b002dc7e50b09e2a85bbcacca5bc6be
If you have wireless keyboard connected and want to disable keyboard on the desktop, you can simply:
killall qtvirtualkeyboard-gtk-helper
Thanks @penk - I will try that and report back (though may take me a day or so...)
The behaviour of the keyboard in the cutiepi shell is generally good, so if we can get the desktop OSK to be like that, that would be a fine thing.
It si curious, though, the the qtvirtualkeyboard seems to block delivery to GUI apps, but not to the desktop terminal, I think. Is there a known reason for that?
And if killing qtvirtualkeyboard proves useful, can we add a setting or button somewhere to enable/disable the qtvirtualkeyboard as and when needed?
Oh! Forgot to mention that I spotted another oddity with the image_2022-03-28-raspios-cutiepi.zip build.
It does not seem to be setting the system time (via NTP or otherwise) whereas the prior build did seem to - not sure why.
Noticed this when doing an apt-get, and the call was rejected because the system date was too far out of synch.
Have to do a "date" update manually to force the date/time to get apt etc. to work now.
@imaclmaca agree, desktop virtual keyboard should detect input device (via udev?) and hide itself when a keyboard is connected, our implementation is quite primitive at the moment.
You should have NTP, you can adjust the timezone in Settings page.
Another build with Ctrl key added into Terminal layout: https://drive.google.com/file/d/1xMCnQs4wtblL698N_S9MgZ8WGowoTmht/view?usp=sharing
@imaclmaca agree, desktop virtual keyboard should detect input device (via udev?) and hide itself when a keyboard is connected, our implementation is quite primitive at the moment.
I do not know how to auto-hide the OSK if a real keyboard is present, but I suppose that would be good - that said, displaying the OSK even when an external keyboard is connected is not necessarily a bad thing, so long as both keyboards can work (and the cutiepi OSK is easy to hide if it is not wanted.)
I'm pretty sure I have had phones that did this (still displayed the OSK even when a "real" keyboard was available) and it was not a problem in practice.
You should have NTP, you can adjust the timezone in Settings page.
Yes... I always set the timezone and locale on first boot for any new image, but for whatever reason the runtime is not picking up the proper time following a reboot, so it is not querying NTP I assume.
TBH, I have not seen a raspi do that before - all of mine seem to get the time OK (though it often takes them a while to sync up) so it just seems odd...
Another build with Ctrl key added into Terminal layout: https://drive.google.com/file/d/1xMCnQs4wtblL698N_S9MgZ8WGowoTmht/view?usp=sharing
Hmm, downloaded the 2022_03_30 image for the google drive and tested it - not seeing the CTRL key; is there something I need to do to enable it?
Also, NTP still not synching the system times automatically for me on restarts...
In the meantime, I have been playing about with "onboard" as my OSK, rather than matchbox-keyboard; do not know why I have not used "onboard" before, since it seems really capable!
Default theme is ugly, but there are several others I do like, notably "nightshade" and "droid", that might suit fine.
And my initial look suggests it is easier to configure and integrate than the qtkeyboard too, so certainly worth a look, I think.
For Ctrl key you need to press on the globe icon and switch to the Terminal layout:
Doh! OK, yes, that works!
And the resulting OSK seems usable so far, at least for what I have tried!
As an aside, I note that, once I set the mode to "Terminal", the label on the space bar changes to "Space" (which I like) rather than showing the selected locale, but when I go to the symbols tabs of the keyboard, the space bar label changes to "American English" instead, which I do not find cosmetically pleasing (and it is possibly wrong anyway, since that's not the actual locale I would have selected...)
But - ignoring the label assigned to the space bar, all the symbols" keys (both pages) seem to be generating the correct characters for me anyway (apart, possibly, from the Euro symbol € but I think that is a problem with the font I have not displaying it rather than a keyboard issue!)
@imaclmaca thank you so much for the testings! Yeah the label on space in other layouts are default behavior of qtvirtualkeyboard. Terminal is our custom layout. I'll do more test and make a release with these changes.
Closing this one for now with new image release. BTW ntp package was added.
https://github.com/cutiepi-io/pi-gen_stage4.5-cutiepi/releases/tag/2022-04-01
@penk - I know this ticket was closed, but some further follow-up testing I was doing, and a few things I really should have spotted before.
- The OSK in desktop mode is much improved, especially the "Terminal" language setting (which adds CTRL key etc.) but for some reason my tablet never remembers that setting and keeps defaulting back to "British English" each time I cycle the power - presumably to match my locale setting? Minor, but annoying.
- A more serious one: I never noticed before, I really should have (sorry), but the newly added CTRL key does not actually work when I use it in the desktop terminal. NOTE: It works absolutely fine in the cutiepi shell terminal. (I was trying to CTRL-C a wayward task, and it did not work - the same thing tried form the cutiepi shell was fine.)
- The OSK cursor keys don't seem to work in the desktop terminal either (again, they work fine in the cutiepi shell terminal.) I mainly use these for history recall or line editing in the terminal, so they are handy to have, but seem to been non-functional for me.
And: Thanks for fixing the NTP stuff, seems to be working now: Though, I note that the tablet always starts up showing the "old" time, then switches to the new time (which is perfectly normal) but the cutiepi shell does not seem to update to show the new time until I pull down the dropdown menu... As soon as I do pull the menu, the time switches to the "new" value correctly. (The desktop mode does not do this and seems to update the time in the taskbar automatically without intervention.)