Red, Green and Blue keys in Keyboard plugin

The current Keyboard !Configure plugin makes reference to Red, Green and Blue keys.

I believe this is a reference to one particular model of Iyonix keyboard that came with the Windows and Menu keys re-badged as coloured keys.

I could be wrong, but I doubt anyone is making use of such a keyboard now, and since these keys were just rebadged versions of the standard keys present on 90% of modern keyboards, I propose that it would make more sense to rebrand these as:

Left Win(dows) Key
Right Win(dows) Key
Menu Key

If people don’t like the word Windows (or Win, which is shorter), we could refer to “Start Key” instead, but that’s up for comments.

Ultimately, we probably want to jetison that Macros section of the window, and have a button which leads to more comprehensive macro-editing a-la !HID. However, that’d be significantly more UI work, and probably something for the “Bounty” area.

I think this could be achieved with just a Template/Res file change (I’ll need to look through stuff) which I’d be willing to do myself, but I wanted comments beforehand. Also, I don’t know the public submission procedure /blush.

What do people think?

I believe this is a reference to one particular model of Iyonix keyboard that came with the Windows and Menu keys re-badged as coloured keys.

Yes, I think you’re right. There’s some talk about it on the Iyonix developer website (near the bottom, under “extra keys”), but by the time I got my Iyonix it seems Castle had given up on the idea of getting custom keyboards.

Also, I don’t know the public submission procedure /blush.

I can’t find where it’s mentioned on the wiki (I think it’s on there somewhere!) but I believe it’s just a case of making your changes and then emailing code@riscosopen.org.

What do people think?

Sounds OK to me. It would be good if we had a keyboard plugin/driver that could allow full custom keymaps to be specified, e.g. to make the menu key act like the menu mouse button if you’ve only got a two-button mouse (or a keyboard with two-button trackpad/trackball), or for portables like the Touch Book/Pandora which don’t have the full complement of keys in the first place.

What do people think?

Makes sense to me. Calling them Win(dows) keys does feel a bit incongruous, though. Perhaps Start would be better, or even Command (I use a PC keyboard with my Mac mini, and the Mac Command key seems to get mapped to the Windows key).

OK, I made some (fractional) tweaks to most of the icons in the window, although for size limits (eg. people using System Font) I went with “Win key”. I suspect “Start key” might fit (just) if people feel strongly.

You can see a screenshot at http://www.armini.co.uk/Keyboard.jpg

Feedback welcomed.

With RISC OS 4.39 and 4.42 You have an option of Num Lock enabled.

Also with the Macro keys, you have Alone and +Ctrl what about adding Shift and Shift&Ctrl ?

Only a pathetic RISC OS fanboy would mind if the keys with the Windows logo is labled “Win key”.

Well, here I am. ;)

Why not call them “Logo key”?

There are keyboards with generic logos, a very few with Tux or the Ubuntu logo, the keyboard of coming AmigaOne X1000 even sports the Boing Ball. Last, but not least there are Apple keyboards.

I am perfectly aware that 99.9% of the new RISC OS systems will be used with bog-standard Windows keyboards, but on the other hand this opens up a new merchandise idea: self-adhesive ROOL logos for the Win keys, either as plain sticker or more preferably as a small plastic nub.

Thanks for the excellent suggestions, Kevin :)

I think the actual triggers for these keypresses are part of the Wimp/OS since the plugin only runs to edit the settings. So, to add the other options, one would need to not only update the plugin, but also the triggers in the OS. That’s more than I have time for this week (still working through ARMinis), I’m afraid.

There’s clearly a project here (bounty?) to integrate some of the functionality of !HID (supplied with every ARMini) into the OS in a more manageable form. Mostly this would be UI work with some possible changes to the keyboard driver and/or wimp.

Also with the Macro keys, you have Alone and +Ctrl what about adding Shift and Shift&Ctrl ?

Using Shift with the Logo keys is tricky as “Shift+left Logo key” is “right Logo key” and vice versa. (Result is the same key code.) Same for Ctrl+Shift+Logo key.

I think it is delibrately left out in the !Configure plugin.

You can see a screenshot at http://www.armini.co.uk/Keyboard.jpg

Since the frame already says “Macro keys” then you could probably drop the ‘key’ bit from each key name and save some space in the window.

I’m still not terribly keen on the idea of “dropping a directory on my Win key”…

I agree that “logo key” is more neutral, but I suspect that users unfamiliar with expanded keyboards (most RISC OS users, it seems) would struggle to find “logo key” at all informative. Especially as the menu key is also a logo.

Plus… groan at Martin’s joke, but point noted!

I think any of the offered suggestions (Logo, Start, Command) would be preferable to ‘Win’ or ‘Windows’, simply because the OS the plug-in’s running on isn’t Windows.

for size limits (eg. people using System Font) I went with “Win key”

Is that really a consideration? Looks like there’s plenty of room in the window design to expand the icon sizes if you need to. And Andrew Conroy’s suggestion of omitting the ‘key’ word seems sensible.

I agree that “logo key” is more neutral, but I suspect that users unfamiliar with expanded keyboards (most RISC OS users, it seems) would struggle to find “logo key” at all informative.

If they’re delving into Configure to set up macros, then I’m sure they can work out what ‘Logo’ or ‘Start’ key means. And of course they can always use Interactive help, which could explain the situation more fully.

Understood, although it is still hard to get away from the fact that keyboards have Windows logos printed on the keys…

Hold on, what about “Flag” key?

(Later edit…)

OK, I did a bit of a check online. Officially it is called the Windows key. However, it is acknowledged that on non-Windows systems, this is a bit offensive. Other names include the Start key (as I suggested above), or the Flag key (which came to mind earlier). On the Mac, it is called the Command key, and on Unix/Linux systems it can be called the Meta key. System key is also an option. Gulp.

Having given it a lot of thought, I’ve gone with Flag key, because it is immediately descriptive. Additionally, I’ve taken advantage of the online help (good suggestion) to mention that it is the Windows key. I kept the word “key” in it because of the Menu entry – there was room for confusion because of the name of the middle mouse button. I appreciate this should be obvious, but I think it best to be crystal clear. I’d like to think that was the Acorn philosophy, although I suspect that’s rather rose-tinted ;)

Any objections?

In the “Official” windows keyboard scan code specification, its called the “GUI” key (scan code &E3 = keyboard left GUI, scan code &E7 = keyboard right GUI)

I don’t know which “official” you’re talking about… Cerilica “officially” registered the keycodes under the “Logo” key name a long time ago.

I agree that “logo key” is more neutral, but I suspect that users unfamiliar with expanded keyboards (most RISC OS users, it seems) would struggle to find “logo key” at all informative. Especially as the menu key is also a logo.

Until you can show me the Registered Design in question, the menu key bears an icon, not a logo.

although it is still hard to get away from the fact that keyboards have Windows logos printed on the keys

Mac keyboards certainly don’t have a Window on them and treat such keys as the Command button (which carries an Apple Logo these days). If we wanted to be traditional we might use “Meta”, but I think “Logo” won the day some time ago. The additional key names defined for the MMK keyboard were:

Logo, Menu, Power, Sleep, Wake, Help, Web, List, Link, Find, None, Less, More, Play, Stop, Rewind, Forward, Eject

The key name is “Logo”, but feel free to say “which may bear a flag, fruit or geometric symbol” if it would help.

I don’t know which “official” you’re talking about… Cerilica “officially” registered the keycodes under the “Logo” key name a long time ago.

Microsoft Doc here
By “Official” I meant according to Microsoft !! (hence the quotes)

Whilst I appreciate the point about “Logo key”, running through google shows very few hits for it being called that elsewhere. “Flag key” gets hits right off the bat, as does meta key (albeit for the diamond logo). Windows key gets the most hits (obviously). Unfortunately I got no hits at all for GUI key :(

I’m trying to pick something that is informative to a user, based on the most likely keyboards to be connected. I put it to you that most (UK) users would be unlikely to go out and choose to buy one of those (rather unpleasant IMHO) Apple US keyboards to connect to a RISC OS computer. It seems rather more likely to me that they would use an off-the-shelf Logitech, Genius or Cherry board (or, heaven forbid, a generic one). Certainly Castle sold Logitech, Kensington and Cherry, whilst CJE tend to sell Logitech and Genius (I believe). We sell Logitech and Microsoft, with the odd Cherry.

I’m not averse to expanding the help as you suggest, but given that !Help tends to be completely ignored by most people, the on-screen prompt needs to run the gauntlet of being as clear as possible for the majority of users.

It seems like there’s a lot of focus on what the symbol on these keys look like, and not so much on what they do. “Logo key” and “flag key” give you no indication of what might happen when you press the key.

At least “command key”, “GUI key”, “win key” and “start key” give some clue about functionality. By that token, perhaps you’d want to call them “left macro key” and “right macro key”, or is that just too obvious!?

I’m not advocating or opposing any term given above, just pointing out (because no one else seems to have done so explicity) that “logo key” and “flag key” seem a little…superficial in this respect. Though in their favour, they do make it crystal clear which key is being referred to. But what’s more important in the name?

At risk of further complicating things, I’ll add that Wikipedia refers to a number of Modifier keys, including the Super key under Linux or BSD (although a citation is missing for that one). I’ve not yet checked the various talk pages, which may include some useful discussions.

What got me started on this was that several customers independently contacted me wondering what these mysterious red/green/blue keys referred to, under “Macro keys”. I think they understood what they could be used for, but not what they were physically on the keyboard.

That’s why I’ve been concentrating on making it clear which keys we’re referring to. They are in a section marked “Macro keys”, so I think that portion of W P Blatchley’s comment is covered, and the boxes below allow stuff to be dragged in (files or folders).

I was thinking of writing a short bit of code for the Library folder which would be called MenuClick, and that would allow one option for the Menu key to simulate a menu click without further OS changes (the MenuClick exe would run, and fake a menu click at the current mouse co-ords).

I had 5 minutes spare, I knocked this together. It fakes a MENU click at the current mouse position. Save it to the library folder as “menuclick” and set the “blue” (or whichever) key macro to simply “menuclick”.

DIM b% 9
SYS"OS_Mouse" TO x%,y%,,t%
b%!0 = (x% AND &ffff)
b%!2 = (y% AND &ffff)
b%?4 = %010
b%!5 = t%

SYS"OS_IntOff"
FOR i% = 0 TO 8
  SYS"XOS_Byte",138,9,b%?i%
NEXT
SYS"XOS_IntOn"

While I’m on a roll, here’s another little BASIC program that can be put into the library as “wimpecho”. It sends its arguments as key presses using Wimp_ProcessKey. I’ve got one of the macro keys aliased to “wimpecho (my email address)” so I don’t have to keep typing my email address into the ROOL login form! :)

NOTE – there was a bug in this code, I’ve edited this post to fix it.

REM Send command line args to the wimp as key presses
REM syntax wimpecho <text>

ON ERROR ERROR EXT 0,REPORT$+" at "+STR$ERL

DIM buff% 1024, poll% 256
mask% = %11100011100101110000
size% = 0
dde% = FALSE

SYS"Wimp_Initialise",310,&4B534154,"wimpecho",0,0 TO WimpVersion%,TaskHandle%

SYS"XOS_SWINumberFromString",,"DDEUtils_GetCLSize" TO swi%;flags%
IF (flags%AND1)=0 THEN
  SYSswi% TO size%
ENDIF

IF (flags%AND1) OR size%=0 THEN
  SYS"OS_GetEnv" TO buff%
  size% = FNstr_len(buff%)
  DIM cmd% size%
  PROCmemcpy(cmd%, buff%, size%)
ELSE
  dde% = TRUE
  DIM cmd% size%
  SYS"DDEUtils_GetCl",cmd%
ENDIF

REM A non DDE command line has the program name on the front, in this case
REM it will be of the form: BASIC -quit "our_program" ...
REM So skip the first three "words" of the command line (ie 3 spaces)
l% = 0
IF NOT dde% THEN
  s% = 3
  WHILE s%>0
    WHILE cmd%?l%<>32:l%+=1:ENDWHILE
      l%+=1:s%-=1
  ENDWHILE
ENDIF


REM process the remaining string
WHILE l% < size%
  SYS"Wimp_Poll",mask%,poll% TO reason%
  IF reason% = 0 THEN
    SYS"Wimp_ProcessKey",cmd%?l%
    l% += 1
  ENDIF
ENDWHILE

END


DEFPROCmemcpy(to%,from%,size%)
LOCAL i%
FOR i% = 0 TO size% - 1
  to%?i% = from%?i%
NEXT
ENDPROC


DEFFNget_str(a%)
LOCAL a$
WHILE ?a%>=32
  a$ += CHR$?a%
  a% += 1
ENDWHILE
=a$


DEFFNstr_len(a%)
LOCAL len%
WHILE ?a%>=32
  len% += 1
  a% += 1
ENDWHILE
=len%

On a related note, I’ve noticed that the macro keys don’t work if the focus is in an application that doesn’t correctly handle Wimp_EKeyPressed events. I assume that what these bad apps are doing is failing to pass on the key press with Wimp_ProcessKey.

So, if you notice such behaviour, please poke the app’s author to fix it! :)

By the way, passing on key events seems not to be required if the app sets bit 8 in the poll mask. This bit is described as “Don’t return Key Pressed; Queue it”. What does “queue it” mean, does anyone know? Does the event simply get passed to the next candidate, as if Wimp_ProcessKey had been called?

By the way, passing on key events seems not to be required if the app sets bit 8 in the poll mask. This bit is described as “Don’t return Key Pressed; Queue it”. What does “queue it” mean, does anyone know? Does the event simply get passed to the next candidate, as if Wimp_ProcessKey had been called?

In the PRM there are three events which, when masked, have the comment “queue for later handling” against them. These are Redraw_Window_Request, Mouse_Click and Key_Pressed. The PRM says:

Note that the bits above which are marked ‘queue for later handling’ stop the Wimp from proceeding, i.e. it stops all other tasks too.

This doesn’t seem consistent with the behaviour you’re observing though! I must say I’ve never understood this either. Can anyone explain?

On a related note, I’ve noticed that the macro keys don’t work if the focus is in an application that doesn’t correctly handle Wimp_EKeyPressed events. I assume that what these bad apps are doing is failing to pass on the key press with Wimp_ProcessKey.

So, if you notice such behaviour, please poke the app’s author to fix it! :)

Organiser comes to mind. If it has a reminder open, it doesn’t pass on keys, even ctrl-shift-F12 which I find very annoying.