Onboard

Can we get an option to filter/replace certain key combos?

Asked by Jeff Sereno

Hi,

I've employed OnBoard in a kiosk application where the end-user types in some personal details and then submits it using a touchscreen. We're using the Chromium web browser to do this to make use of the nifty "kiosk" mode that hides unnecessary elements of the web browser.

Some users are simple and enter all their details either completely in lower case, others hit Caps and do it completely in upper case while others are pedantic and do it in proper case. All this is fine - no issues.

The issue is when we get the occasional user who needs to write all in capitals, but rather than use the Caps button, they decide to double-tap the Shift key instead to lock it in.

This is all fine and dandy until the user taps on the submit button on the page. This is the same as pressing SHIFT+ENTER on a regular keyboard (or SHIFT+CLICK with the mouse on the page's submit button), and unfortunately in Chromium (and Chrome) this means open the next page in a new window. Sadly kiosk mode does not prevent this new window opening.

CAPS+ENTER or CAPS+CLICK does NOT cause Chromium to open a new window.

Long story short is I have been unable to disable the SHIFT+ENTER combo in Chromium or elsewhere and am now looking to see if we can have a future feature added to OnBoard to define key combos for filtering or replacement with a user-defined combo instead (eg: if SHIFT+ENTER is detected, replace with ENTER only) so that I am not forced to delete the Shift key off OnBoard's display altogether to curb silly end-users.

Alternatively, is there a way to disable the double-tap locking of the SHIFT key? I'd like the user to discover that if they want full caps, then they should rightfully use the Caps key instead.

Question information

Language:
English Edit question
Status:
Solved
For:
Onboard Edit question
Assignee:
No assignee Edit question
Solved by:
marmuta
Solved:
Last query:
Last reply:
Revision history for this message
Best marmuta (marmuta) said : 		#1

Hmm, we'd have to think about that. Perhaps an option to release latched and locked sticky keys when pressing certain others like RETURN would make sense.

Right now I can't think of a way to ignore modifiers when pressing RETURN. Have you tried remapping SHIFT+RETURN with xmodmap? I'm not sure this can be successful, though.

What we do have is a mechanism to change the behavior of sticky keys (modifier keys and layer buttons). To disable the locked state for modifier keys except NumLock you could do the following:

gsettings set org.onboard.keyboard sticky-key-behavior "{'all': 'cycle', 'modifiers': 'latch', 'NMLK': 'cycle'}"

'CAPS': 'lock' is assumed by default, but you can change that too if necessary.

The behaviors are:
    cycle - cycle through latched and locked state (default)
    dblclick - only lock on double click
    latch - latch only, no locking
    lock - lock only, no latching

Also, you can configure Onboard to auto-release latched and locked keys after a period of inactivity, where inactivity means no keys are pressed. Here's an example that sets up a delay of five seconds:

gsettings set org.onboard.keyboard sticky-key-release-delay 5.0

Revision history for this message
Jeff Sereno (jsereno) said : 		#2

That is PERFECT. Just updated my test PC to 0.98 and tried your suggestion - the Shift key now cannot be locked on but Caps still works as expected - brilliant.

It doesn't directly prevent the SHIFT+CLICK issue, but the likelihood of the issue happening again will be vastly reduced because the end-user will be frustrated by the Shift key not sticking that it will force them to use Caps like they should have done in the first place!

Cheers!

Revision history for this message
Jeff Sereno (jsereno) said : 		#3

Thanks marmuta, that solved my question.

Revision history for this message
marmuta (marmuta) said : 		#4

Great, I'm glad that helped. Upgrading to 0.98 wasn't strictly necessary, though. Those options are in 0.97 too, only at the old gsettings path "apps.onboard".

You may want to try the sticky key delay too, even at something larger, like 30 seconds. With that users can't leave stuck modifiers and switched layers behind (for long) to confuse the next person.

Revision history for this message
Jeff Sereno (jsereno) said : 		#5

Yes, I noticed the paths had changed in gsettings. Figured I may as well get used to 0.98 anyway moving forward.

I left the sticky delay at 5 seconds. People are forced to use the Caps key if they want to type all in caps, and this means there is nearly no chance of the average user inadvertently tapping out SHIFT+CLICK on a submit button. So far today, it's worked well! =)