On screen keyboard

I have Brewblox on a touchscreen using kiosk mode from a rpi. I miss the opportunity to fill inn text fields and number fields. I have tried to install different virtual keyboards with no success. Any chance a pop-up keyboard when touching text and number fields be implemented in Brewblox? (f ex possible to enable pop up keyboard from settings)

Maybe something like this could be useful to make a keyboard? https://mottie.github.io/Keyboard/index.html

What was the problem with the virtual keyboards on the Pi?

We can certainly add a virtual keyboard to the UI, but may as well first try and get the OS-level one to work.

I found out that the easiest way to add a keyboard was as a chromium extension. Keyboard pops up in Brewblox in text/number fields. I could type inn letters/numbers, but when hitting enter what I have typed in disappeard and Brewblox didn’t reacted. F ex if I try to change a temp setpoint, I could perfectly fine type in f ex 67, but when I hit enter Brewblox told me that I have hit enter with no value.

I have also tried to install matchbox and florence keyboard directly to raspberry. Matcbox was not a pop-up keyboard. And florence gave me headache, did not get it to work at all.

If there is an easy solution to make virtual keyboard from chromium extension work, that would be great! Unfortunately I don’t have the knowledge to make it work :sweat_smile:

I have tried this(and a couple of others,
Same result): https://chrome.google.com/webstore/detail/virtual-keyboard/pflmllfnnabikmfkkaddkoolinlfninn

At a guess, there’s some weird interaction with our code for input fields and how the virtual keyboard sends key presses.

I’ll check whether I can get that to work. Kiosk mode is something we want to support - but preferably without adding more dependencies to the ui.

Kiosk mode is awesome! Looking forward to see what you can do!

I can confirm that chrome extensions for virtual keyboards are useless.
The Pi virtual keyboard OnBoard did work.

To install:

sudo apt install -y onboard

To configure:

  • Pi start menu -> preferences -> onboard settings
    • General -> start onboard hidden, show floating icon when onboard is hidden
    • Window -> force window to top
    • Theme -> Nightshade (the default theme is -really- ugly)

Restart your Pi to apply the window setting.
When running, start onboard before launching kiosk mode.

I’ll make an issue for us to check out virtual keyboards on our end. You’re not the only one using kiosk mode, and we’d rather have things work out of the box. I can’t make any promises about how and when we’d implement it.

im about to give this a whirl. but if you do implement… I would think that even if it was just a numbers pad for temp and duty setting that you implemented would be sufficient. obviously I can’t speak for all but for me. any editing to system setup I would rather do from a computer. so full keyboard implementation would be awesome but not necessary… if

We’d strongly prefer some global solution that doesn’t need to be configured for each input field.

For the common use cases of eg. adjusting setpoints, next release already includes a widget that shows buttons / sliders for multiple predefined values and ranges.

yeah I suppose that makes sense. so I tried to use the onboard option but it doesn’t have any way to set up in raspbian lite from what I could read online. but In my hunt for trying to find a solution for scrollbar removal I was able to navigate to the extension store for chromium and I was able to install an onscreen keyboard from there. only problem is the same to OP had. inputs show but don’t actually take the setting. very oddddddd

OnBoard should be set up on your client running the browser, not the server. It indeed is not compatible with Raspbian Lite, but neither is Chrome.

I’m running chromium in buster lite. (Works raspbian lite too).

I used this write up…

Only thing I had to do different

  • add an 8sec delay to startup due to the load speed of brewblox.

  • add the start script to .bashrc instead of .bashprofile. (Bashprofile removes ability to run brewblox updates)

  • also I use in case IP address changes!!

That does explain. I hadn’t considered the “only install X-server” approach.

It looked like OnBoard had dependencies on Gnome, so that indeed won’t mesh well.

Virtual keyboard support is now on the backlog anyway. I’ll tinker with it soon-ish, but it won’t be part of next week’s release.

1 Like

Soooo with a little research it looks like these extension keyboards need the ability to write to local URL file. Which is an option under preferences of the extension settings of chromium.

Still does not work tho. Could be an issue with order of loading. Brewblox may be started prior to chromium. Or something along those line…

The brewblox UI is just a website: a bunch of html/js/css files downloaded and executed by your browser.

I suspect that the virtual keyboards try to inject chatacters in a place where the JS in the UI isn’t notified . I may give it another try some time, but I wasn’t much impressed with them to begin with: most of the ones I tried were blatantly stealing code / design, and I’d have to find the original first.

Haha. I’m not surprised!!! No worries. I’ll wait for a native one. It will be much better implemented and look better!!! Again thanks for the awesome support!!!

1 Like

this is my RPI solution for the keyboard touchscreen I have.
Virtual keyboard
sudo apt-get install matchbox-keyboard
From http://wiki.sunfounder.cc/index.php?title=10.1_Inch_Touch_Screen_for_Raspberry_Pi

I tried matchbox. I didn’t like it. Took half of the screen. It’s not a pop up keyboard, no auto hide. Maybe you can do some codes to make it do those things, I just did a straight forward installation.

Can’t wait for Brewblox to implement virtual keyboard! That’s great! :sunglasses:

Done that but my onscreen board shows questionmarks instead of characters. Pi setup localisation is set to english (UK), generic 101-key PC.
How can this be resolved?

After this topic, we added on-screen keyboard support to Brewblox itself. It can be accessed from any input field in the UI.
Does that fix your use case, or was there some other reason you needed an on-screen keyboard?