User programmable keyboard layout

The thread about AZERTY keyboards reminds me that the need for user programmable keyboard layout keeps getting more and more important. Many RISC OS user are now using keyboards that have keys whose legends and actions differ especially when key modifiers are used.
I’ve used Keymapper but it can’t cope when Key modifier changes.

Certainly.

I have a bit of rudimentary test code that detects key presses and matches them against known Kana sounds. Actually, the module, akin to MoreKeys just passes keypresses to a Wimp front end and that does the hard work.
If the keypresses match (“hi”, “ha”, “ho”, etc) then the front end will output two Delete keypresses followed by the UTF-8 of the character code of the relevant kana. It isn’t an IME, it won’t do kana→kanji or anything fancy. I just wanted an easier way to ‘type’ kana than looking up stuff in Chars.

Somewhere, nemo is going “grrrrr”. ;-)

The thing is, I don’t want to replace the current keyboard handler. I want to augment it. Kind of like it should not be necessary to write a replacement handler just to be able to deal with some media keys. Most keyboards these days have extra keys. Even my basic model has pushed PrintScrn-ScrollLock-Break down above Insert-Home-PageUp and uses the space to the right of F12 for the following: Power, Sleep, Wake Up. Kind of useless on my Pi (I’m not going to quibble over a 7W power draw!), however it might be nice to have those keys able to do something.
The makes-RISCOS-break Microsoft Media keyboard, as its name implies, offers a number of extra keys. Wouldn’t it be nice if DigitalCD could see them and use Vol Up/Down, Mute, Back, Play/Pause, and Forward for the logically anticipated functions…without requiring a custom keyboard handler (which may not be suitable for some people, French/German keyboards, etc).

I think this is something of a weak point in RISC OS. The PRMs, which devotes pages to hardware descriptions of ADFS on floppy discs and how to fill sound buffers, is entirely quiet about keyboards. It is, apparently, outside the “scope” of the programmer’s reference manuals to describe it. IKHG used to exist, now it doesn’t. Well, it does, but it is too old. There’s the IntKey module, but doesn’t lurking in there effectively mean you’re replacing keyboard functionality?

The current keyboard driver can deal with Japanese. If you load Ovation in UTF-8 mode (hold Alts as it loads), select Cyberbit, and then press Alt-12510 Alt-12522 Alt-12540 Alt-12522 Alt-12463, you’ll have my name. Or you might get “Þêûꯔ instead, because this behaviour only works with Alphabet UTF8, apparently nobody considered a program supporting UTF-8 when in Latin1 mode; though it is probably better doing it as Wimp keypresses.

This can lead to a long rant, so I’ll go eat some cherry yoghurt and let it go…

I have a bit of rudimentary test code that detects key presses and matches them against known Kana sounds

How easily do you think you could produce an “accent module” to enable all characters to be accented? Hit AltGr+L for grave, AltGr+K for acute, etc. Whether it’s “pre” = supply the accent and then the character to be accented or “post” supply the character and then the accent is open to debate.
The wife spoke of the compositors dead key and similar in some typing modes but never having used that I’m able to comment on the pre/post element.

Accent keys on input devices in the simplest implementation simply did not advance the ‘cursor’ so the accent automatically overprinted the following character. Type acute and grave and you get a rough circumflex. And so on. Convention was that capitals were not accented (the accent would be too low).

I realise that this only applies plain ASCII, but it might be worth remembering that we already have a dead-key handler. So Alt+ key will modify the following character if it exists in the character set:

 Key

  [   é acute

  ]   è grave

  :   ü umlaut

  ’   ê circumflex

  ,   ñ tilde

  .   å

  /   ç cedilla

Convention was that capitals were not accented (the accent would be too low).

I don’t think unaccented uppercase meets the requirement, the article Rick referenced specifically mentions the need to accent uppercase.

For the general implementations some parts would be on the fly:
The dipthong ligatures would probably be automated such that oe would result in œ and ae ==> æ, the Guillemets (French/Swiss style quotes) would be double < or > thus << converts to « and >> converts to »

I seem to recall there was a module called SmartQuotes or similar that did conversion of the dumb quotes " " to “ ” on the fly so this has been done before.

I don’t think unaccented uppercase meets the requirement

Diacritical marks in many languages, such as Swedish and Polish, indicate separate letters of the alphabet and cannot be omitted.

The dipthong ligatures would probably be automated such that oe would result in œ and ae ==> æ, the Guillemets (French/Swiss style quotes) would be double < or > thus << converts to « and >> converts to »

I might have a ‘thing’ about this, but with the current keyboard handler you can access all those characters using Alt+ key. I have added the symbols to some of my keyboards, but I remember most of them.

You cannot automate the diphthongs etc, because you might want to type the separate characters. That is especially so with the ligatures ‘fl’ and ‘fi’.

I seem to recall there was a module called SmartQuotes or similar that did conversion of the dumb quotes " " to “ ” on the fly so this has been done before.

Many times, and several text processors provide similar facilities. However, I think that is qualitatively different to typing international characters.

In most cases, it is not convention to omit accents on capitals, it is just an unfortunate side effect of incapable hardware (first typewriters, then low-res displays, then character sets that omit half of the accented characters…). It is possibly an Anglo-centric idea that such twiddles are not really important, but they are…

I rather suspect the general idea of the things like smart quotes worked by trapping the quote keypress and replacing it with the ASCII code of the desired quote. This isn’t quite the same as reading keypresses, interpreting them, removing them and outputting a character code that is outside of the normal character set. So many potential problems, not least that in the majority of RISC OS apps it will appear as random high bit characters…

IIRC TechWriter provides more than one mechanism for ‘remapping’ keypresses.

I’ve used one of these for years to add behaviours like typing the £ key twice to get a euro symbol or pressing the full stop twice to get a decimal point. It also employs the UKey module which I think was written by David Pilling?

I also remapped the ` keypress to give a single or double left-quote (one or two keypresses) and the ’ to give single or double right-quote (ditto). [Three presses gives what is on the keytop! 8-) ]

FWIW decades ago I tried to delve into the keyboard handler area and found it was an utter jungle. May be better nowdays, but if not, avoid for the sake of your sanity!

Jim

Coping with Accents and other special characters is a significant extra complication to my request. I think it will have to follow on once an API is put in to allow full key mapping with shift usage not tied to standard usage.

Can I add in a request for these keys to be accessible from inside a single-tasking Application?

I hate not being able to read the media player keys from inside a media player :@\

I have been looking at the not exactly well documented character input and recalling nemo’s advice to me to write a keyboard handler. I am starting to suspect this is incorrect because… I want to augment the current keyboard system, not replace it.

I think there are several interacting issues at play here:

1. Firstly, the low level keyboard driver needs to pass on any codes that it receives that it does not recognise. Perhaps the best way for this to happen is for the driver to raise a ServiceCall with the code, and if there is no response then the keypress is discarded; leading to…
2. …the keyboard handler (next level up) can reply to the service call with the internal key number of the keypress for all of the regular keys, so things work as they do now, but an extension module can be loaded to provide codes for additional (media) keypresses.
3. We will have to look and see where and how additional keys can be inserted into the “internal key number” table. Acorn’s use of negative INKEY in a byte-wide value somewhat restricts the number of available keys. We should have key numbers defined for stuff like “Search” and “Volume Up” and the usual; but leave the mapping of these to an extension module so they can be altered by the end user if they wish.
4. Outside of the Desktop, the additional keys won’t create ASCII codes so A=GET will do nothing (or should they generate high ASCII codes?), but they should be detectable using -INKEY. If they can be grouped together, isn’t there an OS_Byte to check for a range of keys?
5. These keypresses can be passed along by the Wimp in the high block (along with Fkeys and the like). I think the protocol should require the user to directly check the modifier keys (Shift and Ctrl), instead of wasting space defining the same thing four times over (plain, +Shift, +Ctrl, +ShCtrl). Leave it to the application that wants to handle the keypresses to decide if Shift-VolUp is the same as VolUp. If an extended keypress is given an internal key number, the Wimp will be able to translate this to a keypress event for Wimp_Poll. What about other keys?

I think how well this could work begins with how many spaces exist in the internal key number table. The ideal approach is for every keypress to ultimately arrive at generating both a keypress visible to INKEY and also to Wimp_Poll.

This does not discuss things such as trapping keypresses and replacing content with other content. Let’s get a keyboard able to respond to all keys and have them visible to software both in and out of the Desktop.

Looks like things may be slightly simpler for USB – http://www.usb.org/developers/hidpage/Hut1_12v2.pdf – it looks like the media keys are available in a different code space from the regular keys (described from p75); but at least it seems more standardised than the mess that is PS/2.

Here’s some older info for PS/2 – possibly only relevant to the RiscPC/A7000 these days:
Basic PS/2 scancodes: http://www.computer-engineering.org/ps2keyboard/scancodes2.html
For an idea of some of the … uh … issues: https://www.win.tue.nl/~aeb/linux/kbd/scancodes-6.html
That’s why the extras should be a module and not baked into the keyboard routines.

We will have to look and see where and how additional keys can be inserted into the “internal key number” table.

I have a table of key, key+shift, key+ctrl, key+ctrl+shift I was using while twiddling with Filer keyboard shortcuts late last year, before I hit some excessive working hours. Must get back to that stuff.

That’s why the extras should be a module and not baked into the keyboard routines.

Should that read …be a language specific module?