Three small updates to the Keyman Desktop 8.0 keyboard options feature are proposed: testing for base layout, on screen keyboard-specific rules, and providing feedback to the end user.

Introduction

Keyboard options were introduced in Keyman Desktop 8.0 in response to a common issue – many keyboard packages include multiple keyboards to cater for minor configuration changes. For instance a Tigrigna package has both Eritrean and Ethiopian keyboard layouts, with only a single character difference – the question mark symbol which differs between the two countries. Or Greek keyboards which differ in how the diacritics are typed.

With keyboard options, the keyboard developer can present the user with a dialog box to let them choose how they wish to use the keyboard. This is both less confusing and more flexible than having multiple keyboards.

Now when reviewing this feature a couple of weeks ago, we realized that with some small tweaks, it would become even more useful.

Proposed New Features

Three small updates to the keyboard options feature are proposed:

• Testing for base layout. This would enable you to have rules conditional for a French base layout, for example. This, combined with the improvements to mnemonic layouts in Keyman Desktop 8.0, should make it possible to cater for all European base layouts with a single keyboard.
• Allowing for On Screen Keyboard-specific rules. This would back up the functionality described in my previous blog post Keyman 8.1 Keyboard Language Proposal: Dynamic On Screen Keyboard and make the dynamic on screen keyboard more flexible.
• Add feedback on option changes via bubble and icon. While this needn't be limited to notification of option changes, some sort of feedback is really pretty essential for keyboard options to be most useful.

Testing for Base Layout

The test for base layout could be implemented with a special system store, for example:

if(&baselayout = 'FR') + 'q' > 'that key next to Caps Lock'
if(&baselayout = 'EN-US') + 'q' > 'that key next to Tab'

Determining how to identify the base layout has not yet been discussed.

Testing for On Screen Keyboard-specific rules

Again, this could be implemented with a special system store. In the following example, the 'Q' key would always show with a capital Q, even though the output would be lower case:

if(&osk = '1') + 'q' > 'Q'
if(&osk = '0') + 'q' > 'q' c not technically necessary but shown for completeness

Giving feedback via balloon or icon change

The details of how additional icons could be stored in the keyboard (and the preferred image formats) are not settled. However, in principle it could work as per this example:

store(happy-face-icon) "happy-face.png"
store(happy-message) "Keyman is now happy"
store(sad-face-icon) "sad-face.png"
store(sad-message) "Keyman is now sad"

store(sad-option) "0"

+ 'a' > seticon(happy-face-icon) showhint(happy-message) set(sad-option='0')
+ 'b' > seticon(sad-face-icon) showhint(sad-message) set(sad-option='1')

Determining the icon to use when the keyboard is initially selected would also need to be covered. At this stage, it is not anticipated that the icon would change in the menus or in the configuration screens, but feel free to ask for this – now's a good time to ask!