OSK strange behavior with AltGr

My keyboard uses the AltGr key for many assignments. I have set things up so that the AltGr combinations also work with Ctrl-Alt for those who don’t have two Alt keys. The setting for “Distinguish left and right Alt” is checked. The keyboard compiles with no errors and everything works correctly when I test the keyboard in the Keyman editor or (after installing) in a word processor.

When I activate the OSK, things are fine at first. But when I press AltGr (either physically or by clicking the button in the OSK) the left Ctrl key also lights up and the keys turn blank.

If I click on the left Ctrl, then it turns off and things behave as expected:

Notice in both screen shots that the characters shown in light type at the upper left of the keys do not match the US-English keyboard. I am an American with my system default set to US-English and hardware purchased in the US. This mismatch does not happen when I test the OSK within Keyman Developer, only when I install it and actually use it on screen.

Any ideas?

Thanks - David

Hello @southwindows, this seems like the AltGr key is treated as Left Ctrl + Right Alt. Are you using English (United States) for your system keyboard?


And, could you send me the keyboard folder so I can check in Keyman Developer and test it out?

Please go to Keyman Configuration and check which base keyboard you’re using​ and switch it to “English - US”.

Thank you!

Thank you, Nyny. Yes, I am using US-English as the main system language (I have both US-QWERTY and US-International keyboards associated with it, with QWERTY at the top of the list). English-US is the base keyboard in Keyman’s configuration. Here are the files:

grk_poly_u_2_5c.kmn (25.6 KB)
grk_poly_u_2_5c.kmx (43.7 KB)
grk_poly_u_2_5c.kvk (3.1 KB)
grk_poly_u_2_5c.kvks (7.2 KB)

I have tested the keyboard and there’s no issue with right alt key. I think it’s because of the system keyboard. Can you try to remove US-International keyboard?

I removed both the US-International keyboard and a custom keyboard for entering vowels with macrons (not Keyman – created with MSKLC years ago), then rebooted. Same result – all keystrokes work when entering Greek text in Word, but the OSK has the same issue with Ctrl being activated when I press AltGr.

Hi David. I’m glad to see you working on this keyboard! It will be great if it can eventually be submitted to our repo so that the new version is supported.

First of all, may I recommend you update to Keyman Developer 17.0 if you have not already done so? The structure of the files then requires you to have a .kpj in the root folder, and then the .kmn, kps, kvks, bitmap in the source folder.

For the .kmn file, I’d recommend you to update the headings to the modern syntax like this:

store(&version) '10.0'
store(&NAME)    'Greek Polytonic Unicode'
store(&BITMAP)   Pi.bmp
store(&MESSAGE)   'This keyboard requires a Unicode Greek font and a Unicode-compatible word processor'
store(&COPYRIGHT) 'Copyright © 2002–2024 by David J. Perry'
store(&TARGETS)   'desktop web'
store(&KEYBOARDVERSION) '2.0'
store(&VISUALKEYBOARD) 'grk_poly_u_2_5c.kvks'

And remove these lines:

c LANGUAGE x08,x01	c  Greek standard and Ancient Greek
c LAYOUT   x3     	c  Used 3 not 2 bc maybe this is already used for polytonic
c store(&ETHNOLOGUECODE) 'ell grk'
c store(&WINDOWSLANGUAGES) 'x0408'

The language tagging information will be set in the .kps file.

Now, once I set the header statements that way, I immediately got a warning:
This keyboard contains Ctrl,Alt and LCtrl,LAlt,RCtrl,RAlt sets of modifiers. Use only one or the other set for web target.

I set the “web” target because you had included a .kvks and I have “treat warnings as errors” set. That helps me see where there are problems and in this case there are many problems with keyboards if you mix ALT and RALT or even CTRL and RALT.

You have rules like this:

+ [RALT K_I] > deadkey(6)     c the iota subscript
+ [CTRL ALT K_I] > deadkey(6)

I believe you should consistently set your ALT rules to use RALT. I didn’t review them all to see if you have a [RALT K_I] and an [ALT K_I] kind of rule. Those would be problematical as Keyman wouldn’t know what to do.

Also, then you have to not use just CTRL you could use LCTRL or RCTRL. I supposed you could use both, but I’d recommend RCTRL so that your users can still use LCTRL for things like CTRL+C to copy or CTRL+X to cut or CTRL+P to paste, etc. That goes for ALT+A to access select all and other shortcuts.

However, if you need to set both RALT and LALT (and the same for LCTRL and RCTRL) you may do so, you just shouldn’t mix plain old ALT and CTRL if you also use the Left or Right keys.

So, I suspect that’s where the problem is arising right now.

Since I am eager for you to update the keyboard, I’d like to recommend a few other things if you don’t mind.

  • If this is going to go into the Keyman repository you should choose a keyboard filename structure now before you get too deep into the updates. Don’t name the folder/filenames with a version. Choose something like greek_polytonic. (I just checked and that name is available.). Then that will be part of the permanent URL for your keyboard on the Keyman site.
    • You can look through the repo to see the folder structure. Here’s one example from the SIL Greek Polytonic keyboard: keyboards/release/sil/sil_greek_polytonic at master · keymanapp/keyboards · GitHub
    • The .kpj, kps, kmn, kvks, should all have the same folder/filenames.
    • The versioning is just done in the .kmn file. Each time something gets changed in the keyboard or even in documentation we would bump the version so the user will be notified that a new version of the keyboard is available.
    • I also do not recommend having “Keyboard” or “Unicode” in the keyboard name anymore because all keyboards are keyboards and all keyboards should be Unicode unless a script isn’t encoded. So, for this keyboard I’d recommend just calling it ‘Greek Polytonic’. A benefit is that having a shorter name shows up better in the UI.
1 Like

Lorna,

Thank you very much for the detailed reply. I will adjust the headers as you suggest. I’ve already upgraded to v. 17. The new (to me) package organization has been murky despite spending time with the documentation. Your one sentence about file location helps a lot.

I envisioned the OSK as a help for people learning the layout or in need of some reminders. I do not develop web apps or maintain web sites, so I never set ‘web’ as a target. I wanted to enable users who have only one ALT and CTRL key to use my keyboard. I think the AltGr key is more common now than it was years ago; is it still important to allow for both types of hardware? As I have things now, users can employ either AltGr or Alt+Ctrl and everything works (including using combinations such as Ctrl-C). Enabling the web target will require many changes to the modifier key assignments; is there any reason to use the web version? Perhaps an OSK is not appropriate for this keyboard.

I understand the rationale for not including ‘Unicode’ in the keyboard name. (When I wrote the original, there were many non-Unicode polytonic Greek fonts in use.) But if I drop it, will users of the original understand that this new version is an update, not a different keyboard?

David

Hi again. There are two uses for OSK. One is if they want to turn on the On-Screen keyboard on the computer so they can see what to type. The other is to be able to just type text on the computer without installing a keyboard. That would automatically be deployed by the Keyman system in a location like this one: KeymanWeb.com

However, you are right that if it’s a mnemonic keyboard it may not work.

As far as users not knowing the original keyboard. We have a mechanism to “deprecate” one keyboard for another. So, your new keyboard would/could have (in the .kps / Details tab) to deprecate grkpoly2

When you do that, the grkpoly2 one would show up like this one: SIL IPA keyboard

If you click on that red bar it will take you to the new keyboard:
https://keyman.com/keyboards/sil_ipa

And down on the bottom right you can see which keyboards are deprecated:
image

In those days we were using the filename as a sort of versioning (ipauni11 and ipauni111) An even earlier keyboard was a legacy encoding. We don’t want to keep updating the link, so instead we’ve deprecated those old ones and named it without a version in the name. Now, when someone installs the new one they will be notified every time there is a keyboard update. In fact, it automatically offers to download the new keyboard.

Also, regarding the name, you could add in your Description (also in the Details tab of the .kps) that this is a replacement keyboard for the “Greek Polytonic Unicode keyboard”. If you do that it will definitely come up when the user searches for your keyboard.

It looks like we desperately need to update this page too: Classical Greek Keyboards so we could do that once your new keyboard is online.

I’m not sure the answer to your question about Alt+Ctrl. If users are happy with it, I guess it’s okay. I’ve just not been real happy with keyboards that use them. I do strongly encourage you not to mix RALT/LALT with ALT or RCTRL/LCTRL with CTRL rules. Either always use ALT and CTRL rules or else always use RALT, LALT, RCTRL, LCTRL rules. Otherwise Keyman gets confused.

Hi David! The good news is you don’t need to have rules for Ctrl+Alt, because Keyman has an option to support users who don’t have a right Alt key (also known as AltGr on European keyboards), “Simulate AltGr with Ctrl+Alt”:

This gives us the best of both worlds: we don’t override the left Ctrl or Alt keys unnecessarily (avoiding conflict with hotkeys, etc), but users who don’t have that right Alt key on their keyboard can switch that option on, and Keyman will detect Ctrl+Alt and translate it to [RALT] during keystroke rule processing.

This will also work better on macOS, where the Option key is the rough equivalent of AltGr on Windows, and the Ctrl key is never normally used for character input.

(In general, Linux is similar to Windows in its modifier key handling.)

I would also encourage a web target, because that makes it possible for anyone to use your keyboard online e.g. at https://keymanweb.com/ If you remove the [CTRL ALT K_*] rules and leave only the [RALT K_*] rules, then I expect your keyboard will work just fine on web without additional changes.

(Side note: if you really wanted to leave the [CTRL ALT K_*] rules, then the appropriate resolution would be to change them to [LCTRL LALT K_*]. But I don’t recommend this.)

Documentation and further detail: Keys, Virtual Keys and Virtual Character Keys

Marc,

Thank you very much for this! I had noticed the option in the configuration dialog to emulate AltGr with Ctrl+Alt. I assumed, though, that the rules for Ctrl+Alt had to still be in keyboard. Since this is not the case, I can simplify the code and hopefully have it work on the website as well as locally. It elegantly handles users’ needs, whether they have the second Alt key or not. Good stuff!

I thought about making a Mac version once, but had no idea what to do about Ctrl (which I knew was not used on Mac for keyboard entry). I will revisit this issue.

David

Quick followup: I followed the suggestions from Lorna and Marc, getting rid of the CTRL+ALT entries from the keyboard and using only RALT. The OSK now works correctly as does entering text with CTRL+ALT when the option to do so is selected in Keyman Configuration. :smiley:

3 Likes