PRI #367: Additional modifiers and toggles

Description

To provide a correct user experience, a Numbers modifier key must be present that activates an extended numpad on the alphanumerical block, and a Programmer toggle is needed to toggle between language and programming because more than one single keypress is inefficient.

xpath

None

locale

None

Activity

Show:
TracBot
May 9, 2019, 9:34 PM
Trac Comment 23.26 by marcel schneider <charupdate@e3c7c05a764702d9—2019-05-04T19:10:07.388Z

== Update about System Integrity Protection
Replying to (Comment 23 auralarchitect@…):

[…] And there's a good chance that such a tool would be impossible to install with the restrictions imposed by the fairly recently implemented System Integrity security platform.

[…]

I personally found a solution using a 3rd party tool and continuing to use a previous version of OS X without the System Integrity.


This is no issue, as Karabiner-Elements uses the kernel extensions as pre-built — and pre-signed — binaries. See:
https://github.com/tekezo/Karabiner-Elements
Also:
https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/KernelExtensions/KernelExtensions.html

TracBot
May 9, 2019, 9:34 PM
Trac Comment 23.25 by marcel schneider <charupdate@e3c7c05a764702d9—2019-05-04T10:04:16.274Z

Replying to (Comment 23 auralarchitect@…):

Replying to (Comment 7 verdyp@…):

[…]

It is true that Ctrl it is rarely (if ever) used by the OS, […] But it may be used with Option (and even Shift) to create additional modifier layers in a keyboard layout if necessary.


After having got time to re-implement for the Mac, I can now tell that sadly the Ctrl + Option layer is not functional. About a dozen keys yield the expected graphics, but some keys generate random stuff like cursor movement or tabulations instead, and most keys are unresponsive.

[…]

[…] I believe the most logical & sensible solution on PCs is to abandon the use of AltGr (which is actually Ctrl+Alt anyway) as a Level 3 Shift key and adopt one (or both/either) of the already available and unused Japanese modifiers (Loya or Roya) to fulfill this role. All the necessary underlying definitions and coding are already in place and fully functional. This also alleviates the complications associated with the Menu (Alt) key (moving focus from the text entry field to the menus), and the breakdown/double usage of Ctrl+Alt based keyboard shortcuts.


Consistently, Marc Durdin advises that “other modifiers are also legal.”
<https://blog.keyman.com/2008/06/robust-key-mess/>

This would clearly involve some changes and updates to applications & the possibly the OS, as well as keyboard layouts. But the changes are minor and easy to implement since all the underlying foundation has been in place for decades. This is really the only TRUE SOLUTION to this problem, and it is a very simple and easy one. Technically, nothing needs to change as far as the end-user is concerned.


That depends on whether the target keyboard layout has casing letters on those levels, because Caps Lock can affect only modifier states 0x00 & 0x01 i.e. Base and Shift, and 0x06 & 0x07 i.e. (Shift +) Ctrl + Alt (aka AltGr).

The key can continue to be referred to as AltGr, its scan code will simply be mapped to a different Virtual Key in the OS.


… and the VK to a different modifier, i.e. 0x10, 0x20, 0x40 or 0x80, or eventually 0x08 especially if the Kana toggle is not mapped (otherwise the “AltGr” map and the Kana Lock map need to be consistent).

[…]

> So the only question is where to place the Group 3 selector, or how to emulate it if it's missing on physical keyboards. And if we need to offer a way to "lock" that group 3, which is completely equivalent to lock an alternate keyboard layout, as currently done in Windows with Ctrl+Alt+(F1..F10) or AltGr+(F1..F10), except that these are used instead to switch from one keyboard driver/map/IME to another one developed completely separately.


I think it would be interesting to develop keyboard layouts for a set of languages in synergy, especially for use in locales where the base letters are arranged differently. Ideally each user may constitute his or her own layout palette, like they are already doing, using the Language Bar on Windows to switch back and forth, or Command + Spacebar on MacOS to cycle through the active list displaying on long press. To switch back to the previously used one, a short press suffices. The Windows Language Bar provides dozens of easy-to-set-up and very efficicent direct keyboard shortcuts, using the upper row for mnemonics. Linux has Super (Windows) + Space as a shortcut to cycle forth, and Shift + Super + Space to cycle back; additionally the user may arrange the list conveniently.

Is it not Group 2 that you're referring to? If not, what is Group 2, and how is it accessed? Are we considering the CapsLock state to be Group 2? Although I don't believe CapsLock meets the definition of a another group with its default behavior, it is sometimes used as such on multilingual keyboards.


On the Mac and in XKB that is straightforward provided that the scripts don’t need to lock input in uppercase and/or the user doesn’t like to do so. Basically that is straightforward only for a set of two non-casing scripts, or one non-casing and auxiliary Latin. Two associated standalone layouts developed interdependently, keeping e.g. punctuation consistent, make for a better user experience. On Windows, this uses SGCaps, with the limitations that Auralarchitect is pointing below.

The locking/toggled version of Kana (also known as Hangul on Korean keyboards) has been acting as a Group 2/3 selector in Windows for decades (although it is not generally referenced using that term). But again, nothing new or convoluted is needed. We already have all of the groundwork ready and waiting.


On Windows, Kana is both a modifier bit (0x08) and a virtual key (VK_KANA). The modifier bit may be mapped to any virtual key in the body source, eventually via its alias defined in the header file (by default in kbd.h). By contrast, any scan code that VK_KANA is mapped to, is handled as being the Kana toggle. As we see, the two things may be done independently. Only using either of them is mandatory if a single key is considered for both, because stacking the Kana/Hangul modifier on top of the Kana/Hangul toggle is not a good idea.

While VK_KANA simply toggles the 0x08 modifier bit and allows thus two fully-fleshed sets of layout levels, it is not suitable neither as a toggle between two casing scripts, because Kana and Shift + Kana are out of reach of the Caps Lock toggle.

In order to accommodate the most (or all) existing hardware keyboards, the solution must not require any new keys or even the re-purposing of any additional keys.


That really depends on the way the graphics are laid out. E.g. in Europe we have key ISO B00, aka the ISO-key, that can be used as a bonus modifier, although it is increasingly unavailable. Further, key E00 (upper row leftmost) may be considered too far away from the home keys to be used on a regular basis. It is required for graphics mainly on layouts limited to 2 levels. So this is an ideal candidate for the second graphic toggle as is desirable for locales mapping letters or frequent punctuation in lieu of the usual digits. Thanks to the second graphic toggle, natively available on Windows and in XKB (Linux and ChromeOS), the digits may have a dedicated toggle instead of merging two unrelated toggles into Shift Lock like it was forcibly done on typewriters.

I would propose that the Group 2/3 selector be activated by tapping CapsLock with AltGr held down. Depending on the languages and other circumstances, it may even be preferable for it be directly on CapsLock and to have the traditional behavior of CapsLock be activated with Shift+CapsLock.


That seems to me an excellent idea for the purpose of authoring Arabic or Hebrew web pages directly in HTML, as it is desirable to have a single key performing the switch in both directions. That can be done using two layouts and a shortcut utility like KeyRemap4MacBook, now Karabiner-Elements, the most performative on the marketplace

[…]

This behavior would be simple to implement. This can be easily configured using the 3rd party opensource tool: AutoHotKey. In fact, everything I've proposed (besides individual app support) can be implemented with only several lines of an AutoHotKey script. Implementation at the OS level could not be much more difficult to release as a Windows update.


The very first update of the Windows TSF APIs should be for Unicode support, as a Windows driver based keyboard layout is definitely unable to yield SMP or composed characters through dead keys. But Microsoft have frozen the APIs about a decade after Unicode was set up, without the necessary update. Today, “strong, perhaps unsurmoutable headwinds” are discouraging them from “mak[ing] any changes here.”

[…]

> A more natural placement of the group3 selector is on PC keyboards the "Application/Menu" modifier key combined with a numeric key on the top row.

.

The AppsMenu/Context key is not a modifier key even though its function is otherwise actually nearly identical to that of the Alt/Menu key, except that it activates the context menu instead of the pulldown menus. Due to this fact, this implementation would also require a bit of new programming, it could also be done with AHK.


This key can easily be remapped inside the layout driver (in the header source), and assigned any suitable VK, as opposed to the left Alt key that cannot be safely remapped in the layout driver. Additionally, since Windows 2000 the OS comes along with the built-in Scancode Mapper for Keyboards, whose settings are stored in a Registry key binary file, for all users and needing a reboot to take effect. AHK is indeed more flexible. Personally I use the Windows SC mapper and the Clavier+ shortcut utility, and KeyRemap4MacBook on Snow Leopard (bought refurbished for the purpose of porting keyboard layouts to the Mac).

[…]

.

In regards to the original response to this message by Marcel:

While it is technically possible to map the left and right Option keys on a Mac separately, the critical underlying frameworks that support this distinction and pass it along to the running apps is no longer present and/or functional for many major releases of OS X/macOS. Which means that either support must be supplied by the applications themselves, or an add-on 3rd party plug-in tool. And there's a good chance that such a tool would be impossible to install with the restrictions imposed by the fairly recently implemented System Integrity security platform.


I can’t believe that Apple are going to out Karabiner-Elements, that is since a long time (formerly called KeyRemap4MacBook) the savior of the Mac. I think many people wouldn’t consider sticking with the Mac without being able to use Takayama Fumihiko’s brilliant tool.

Even after fixing the AltGr issue, Windows still has 3 freely usable extra modifiers, XKB has one, and the Macintosh has lost the one it had after the era when keyboard support complied with TN2056.

Moreover, CapsLock sensitivity reach and NumLock aside, Windows has 2 graphic toggles, XKB has equally 2 graphic toggles, while MacOS since ever has only a single graphic toggle, and a single toggle overall.

Using Karabiner-Elements we can emulate on the Mac as many modifiers and toggles as needed — typically one of each — after adding appropriate .keylayout files, probably with the caveat that we cannot seem to get dead keys to work across layouts.

Still there is another way of implementing the missing modifier: inside a single .keylayout by a long list of remappings, as has been done for the 6-levels German Neo keyboard layout.

I may be some potential work around for this, but I believe it would most likely require an update to the underlying keyboard driver from Apple. And that is not something I would count on getting from Apple. But it's certainly not impossible. They clearly have the resources. It's just their willingness to cooperate and comply that always seems to be the issue.


These statements fully match what I experienced when I’d reported the Option key bug (URL in file linked from page cited above).

I spent quite a long time attempting to get a Mac keyboard layout with separate mappings for left and right Option to behave and function according to its design and I never was able to do so. All of the most reliable and knowledgeable sources I could find and convince to interact with me each told me definitively that "No, that is not possible with OS X".


Actually it isn’t possible *any more.* It really *was* possible when the German first implemented the Neo layout. Later, using KeyRemap4MacBook, it started working *again* on the Mac.

I would LOVE to be proven wrong, but I have given up hope at this point.

Although, I don't believe that such a mapping is actually absolutely necessary,


It is absolutely to get decent keyboard layouts for those locales using THIN SPACE as a group separator, in compliance with SI (BIPM); or rather, given THIN SPACE is wrecked, NARROW NO-BREAK SPACE to achieve the expected effects (see L2/19-169).

Using keyboard layouts with three sorts of graphic modifiers instead of two is useful and therefore good practice also in all other locales.

For one thing, CapsLock on Macs can function as a fully, unlimited group 2 with all the same modifier states as Group 1, whereas Windows can NOT do this. There are many restrictions in Windows regarding the CapsLock state (only single BMP codepoints per key, no dead keys, no ligatures, incomplete (or no) support for shift states above level 2…). None of this applies to Mac.


Shift states are supported until level 4 provided that the associated modifier bits are 0x07, which is not suitable as we have seen. Therefore, the actual groups are dead groups, accessed via a group selector dead key as implemented by Karl Pentzlin of Germany. This may easily yield up to 11 groups, raising to 12 the total number of groups. Enough to map all required letters in the Base and Shift shift-states, as a single Group 2 has proven insufficient in practice. Various developers sticking with it have ended up with either incomplete language support, or a complex group map discouraging fellow developers from adopting the scheme.

It is also possible as I mentioned above to create a separate mapping for Option+Ctrl (just as AltGr does in Windows) but without all the complications and conflicts inherent in Windows.


Again, unfortunately I failed to get this to work. Let alone that this is unsuitable, given that we cannot add Right Option for a Left-Option + Right-Option combo, which is a very convenient one, at least on the home row and adjoining rows.

The issue is that to activate this modifier state which is otherwise unused, the Ctrl key must also be pressed, and this is undesirable and awkward to type.

I personally found a solution using a 3rd party tool and continuing to use a previous version of OS X without the System Integrity. This tool is able to effectively simulate a concurrent activation of left Ctrl when I press the right Option key and so ultimately I did succeed in getting my keyboard layout to work, but not really. I had to revert the distinction between left and right Option and create the distinction with the Ctrl key. But of course this ultimately further limits the number of modifier states that are logistically feasible.


Indeed, yes. — Are you citing Karabiner-Elements? Did you have a chance to test it under “System Integrity” constraints? Should there be a problem, I’m confident that Takayama F. will tackle it, and I hope that Apple will grant him the necessary privileges.

But it is still more than Windows which maxes out at 15 modifier states.


How did you compute that figure ?

BTW, if you're interested in natively supported keyboard layouts for Windows which support the Japanese modifiers (and all 15 modifier states), check out KbdEdit. It is a 3rd party tool, but the keyboards it creates can run on any Windows machine and do not require the tool or any other additional software in order to fully function.


I’m encouraging everybody to rather use KbdUTool, Microsoft’s Keyboard Table Generation Tool (Unicode), included in MSKLC and usable solo as per the EULA. It supports really all modifiers (I’m currently using layout drivers with 35 modification numbers), string output up to 16 code units long, allows to freely map everything, and all Windows users are allowed to download it for free from Microsoft with the MSKLC (that does at least the packaging of the drivers).

The extra modifiers will not be recognized and can not be used by apps. But, every app properly understands and receives any text you can enter in any state with your keyboard.


That is also what I’m experiencing with the Microsoft-style drivers compiled by the original brand tools. On the other hand, apps not properly understanding keyboard layouts do exist on Linux too, e.g. a drawing utility unable to handle dead-key input even from the decades-old legacy French layout.

It also has support for chained dead keys.


So does KbdUTool, MSKLC developer Michael Kaplan reported himself:
<http://archives.miloush.net/michkap/archive/2011/04/16/10154700.html>

It is not free, but I've found it more than worth the price and with the version I purchased I can create and distribute keyboards without any limits that can be used on any Windows machine.


I never used it (beside reading the website) but read about it. I know of a keyboarding developer who ran into issues and reported bugs to the community he is doing development for. Since he moved on to KbdUTool, he is fine. The source code in .klc files is clear text, and you even can generate, check, edit and compile the C sources, so that any bugs KbdUTool may have (it does have 2 coming up under certain circumstances) are easily and transparently fixed. Without extra limitations beyond what Microsoft imposed on Windows.

But just reading through the documentation is very interesting and informative.


I thought so, too, before getting disappointed.

The developer has managed to find or figure out a great deal about many very sparsely documented feature/frameworks of Windows and how to push Windows to the limits of its inherent capabilities.

It does a great deal more than MSKLC, which was not designed to go even so far, as it was ordered by the NSA. Not to empower everybody to write his or her language in its interoperable digital representation.

Microsoft kindly made the software publicly available, and we’re happy to be allowed to even use the nested compilation tooling. What a pity not to do so.

.

Essentially KbdEdit is what MSKLC SHOULD be (but isn't even close)!


It doesn’t matter, really.

TracBot
May 9, 2019, 9:34 PM
Trac Comment 23.24 by marcel schneider <charupdate@e3c7c05a764702d9—2019-01-08T07:21:19.120Z

Replying to (Comment 23 auralarchitect@…):

Thank you for this information. It is key to our project, because we need to have right and left Alt keys to be distinct modifiers. Windows and Linux allow that. The only gap is the Mac.
Implementing your solution of Ctrl+Option is delayed due to other top priorities, but I’ll strive to make it today. Indeed it is not straigtforward to type, and I already started emulating Left Option using the (most famous) third party tool you’re referring to. I’m unable to check whether it still works under the newly tuned system, as my test mac is an older one.

Apple not implementing their spec (TN2056) has been reported as a bug, but the only action I saw was that the spec was moved to an archive folder.

Apple will probably be forced to update their system in accordance with TN2056, because a streamlined keyboard layout for the Unicode-conformant digital representation of Latin-script-using languages in general, and of French in particular, requires that the NNBSP is on left Alt along with the digits in a pad and symbols, and the NBSP is on right Alt along with the upper row digits and the most used ordinal indicator. Also left Alt is used alternatively to right Alt to disable the automatted punctuation spacing needed on a streamlined French keyboard.

So I’ll be glad to get this to work on Ctrl+Option emulating the left Alt (AltGr, while right Alt is Option, getting a one-way-fits-all manner of naming these graphic modifiers). Apple’s users are then expected to lobby downstream for a better UX, once the scheme is in place.

Many thanks again! I’ll post my test feedback a bit later.

TracBot
May 9, 2019, 9:34 PM
Trac Comment 7.23 by auralarchitect@50cd1a9a18375803—2019-01-05T07:21:40.333Z

Replying to (Comment 7 verdyp@…):
This information regarding Mac keyboards is inaccurate on multiple accounts.
.

 

Note that Mac keyboards already have a necessary AltGr/Option key (aka "Apple" key on older keyboards), even if it is placed near the space bar, but not necessarily the Ctrl key found on PC keyboards (Mac keyboards have an "Alt" key). Still the Ctrl modifier key can be emulated on Mac keyboards as well by pressing Alt+Option, so the number of combinations is the same (with or without shift, with capslock/shiftlock, or with the Kana key):

.
No, the Apple key is synonymous with, and was replaced by the Command ⌘ key (which has always been used to form keyboard shortcuts on Macs).
.

 

Mac keyboards are very similar to PC keyboards with the only exception that:

  • the presence of a Ctrl key is optional on Mac, while on PC it is the "Windows" key

.
That is not true. Apple bought the Unix OS around 2000 and built their new "OS X" operating system on top of that. Ctrl was required by Unix and by proxy Macs. Since the introduction of OS X Apple has not produced a Mac keyboard without a Ctrl key.
It is true that Ctrl it is rarely (if ever) used by the OS, and infrequently by 3rd applications; it is used by command line apps and apps using the X Window system (apps ported from *nix OSes] and its function is defined in the OS as command generating and supplemental modifier key. (That means that if used alone with an alphanumeric/symbol key it is meant to invoke a command, not produce text (a character ). This compares to its behavior in Windows. But it may be used with Option (and even Shift) to create additional modifier layers in a keyboard layout if necessary.
.
The Ctrl keys on Mac keyboard map to the Ctrl keys on other PC keyboards (although the USAGE of the Ctrl key in Windows compares most closely to the USAGE of the Command key on a Mac), and yet, technically the Mac Command keys map to the Windows keys in terms of scan codes.
.

  • removing these last two keys (which are placed in the middle of the two following modidiers), the position of Ctrl and Alt modifiers on PC keyboards are just swapped for Alt and Option on Mac keyboards.

.
What?!? Here's a diagram of the left side of the bottom row keyboards: Mac & PC
.
[Ctrl] [Fn] [Option] [Command] [Spacebar] . & . [Ctrl] [Fn]* [Windows] [Alt] [Spacebar]
.
*(The Fn is present on all Mac keyboards and produces a scan code, whereas on PC keyboards it is an OEM space saving solution on laptops to provide access to missing keys, consumer keys and special functions. It does not produce a scan code it alters the scan code of the key it modifies, or sends a proprietary OEM signal/command. It's location on PC keyboards varies)
.
.

  • Applications use common OS accelerators on Ctrl+key on PC keyboards, while they use Option+key on Mac: swap back the two previous positions so that applications don't have to handle the exact relative placement of Ctlr and Alt on PC or Alt and Option on Mac

.
Not true. The Command keys (and optionally the Ctrl keys as well) are used as the basis for keyboard shortcuts (Shift & Option maybe ADDed if more shortcuts are needed), but Option keys and the Shift keys (and their combination) are character producing modifier keys on Mac, not command producing modifier keys.
This is comparable to the use of Shift on PCs; however, the Alt key (actually called the Menu key internally in Windows) is used to activate and navigate the pulldown MENUs on the Windows platform. This function doesn't require the Alt key to be held down; it actually activates the Menu system upon its RELEASE. The arrow keys may then be used to navigate the menus manually, or the user may jump to a menu or command by pressing an 'accelerator' (identified as an underlined letter the menu or command name).
Technically the correct usage of the term 'accelerator' refers exclusively to the navigation of menus (pulldown or context) using letter keys marked by an underscore.
.
.

  • Applications or the OS UI layer will map their software binding accoding to this logical swap, all is needed to be able to select the proper label to display in the UI by swapping them depending on the OS (the OS can identify if the user has a PC or Mac keyboard according to the installed keyboard device driver, via Plug-n-Play or via an out of band option sent whjen negociating the virtual remote session parameters, saying if the key to the left of Space bar is Alt on PC, meaning that AltGr is emulated by Alt+Ctrl, or Option on Mac, meaning that Ctrl is emulated by Alt+Option).

.
Confusing, but... No, Ctrl is Ctrl on a Mac, no emulation is necessary.
The Option and Alt keys are synonymous when comparing keyboard hardware. But the function & usage of the Option key on a Mac is essentially a level 3 shift key (if level 1 = no modifiers, and level 2 = Shift).

 

We get all the necessary compatibility with compact keyboards, and extended keyboards are allowed but not required, to offer the additional keys without needing to use the emulation.

 

Moving AltGr to a new mode 0x10 (or higher) would break this compatiblity. It is not a solution to increase the number of groups and implement a group 3 (or higher) for ISO 8995 (Group 3 is already used for Japanese Kana key or for the Multilingual Canadian keyboard with the Group3 selector)

.
I disagree, in fact I believe the most logical & sensible solution on PCs is to abandon the use of AltGr (which is actually Ctrl+Alt anyway) as a Level 3 Shift key and adopt one (or both/either) of the already available and unused Japanese modifiers (Loya or Roya) to fulfill this role. All the necessary underlying definitions and coding are already in place and fully functional. This also alleviates the complications associated with the Menu (Alt) key (moving focus from the text entry field to the menus), and the breakdown/double usage of Ctrl+Alt based keyboard shortcuts.
This would clearly involve some changes and updates to applications & the possibly the OS, as well as keyboard layouts. But the changes are minor and easy to implement since all the underlying foundation has been in place for decades. This is really the only TRUE SOLUTION to this problem, and it is a very simple and easy one. Technically, nothing needs to change as far as the end-user is concerned. The key can continue to be referred to as AltGr, its scan code will simply be mapped to a different Virtual Key in the OS.
No functionality or features will be lost by removing the Menu navigation behavior of this key, that function can be performed by the left Alt/Menu key. Some users may have to relearn an alternate chord for a few keyboard shortcuts. But the number of users who actually use the Menu key to navigate the Menus (as opposed to the mouse or keyboard shortcuts), or who regularly use keyboard shortcuts is a small and diminishing fraction of users, and they are the most savvy users and will be able to easily adjust.
.
The only cases in which this solution will fail is on keyboards which do not have neither an AltGr nor a right Alt key. This will not be a prevalent issue as I have never seen such a keyboard, but some solution can be developed if/when necessary on a case by case basis. Either the right Ctrl key, or the right Windows key, or perhaps even the Apps/Context key could be used. The number of keyboards which has none of these is surely very small if any actually exist.
.

 

So the only question is where to place the Group 3 selector, or how to emulate it if it's missing on physical keyboards. And if we need to offer a way to "lock" that group 3, which is completely equivalent to lock an alternate keyboard layout, as currently done in Windows with Ctrl+Alt+(F1..F10) or AltGr+(F1..F10), except that these are used instead to switch from one keyboard driver/map/IME to another one developed completely separately.

.
Is it not Group 2 that you're referring to? If not, what is Group 2, and how is it accessed? Are we considering the CapsLock state to be Group 2? Although I don't believe CapsLock meets the definition of a another group with its default behavior, it is sometimes used as such on multilingual keyboards.
The locking/toggled version of Kana (also known as Hangul on Korean keyboards) has been acting as a Group 2/3 selector in Windows for decades (although it is not generally referenced using that term). But again, nothing new or convoluted is needed. We already have all of the groundwork ready and waiting.
In order to accommodate the most (or all) existing hardware keyboards, the solution must not require any new keys or even the re-purposing of any additional keys. I would propose that the Group 2/3 selector be activated by tapping CapsLock with AltGr held down. Depending on the languages and other circumstances, it may even be preferable for it be directly on CapsLock and to have the traditional behavior of CapsLock be activated with Shift+CapsLock. Another option would be to require both functions to use a modifier+CapsLock for activation, and CapsLock alone would only release the toggle.
This mapping is very logical and easy to understand and remember for anyone familiar with using a computer & keyboard.
This behavior would be simple to implement. This can be easily configured using the 3rd party opensource tool: AutoHotKey. In fact, everything I've proposed (besides individual app support) can be implemented with only several lines of an AutoHotKey script. Implementation at the OS level could not be much more difficult to release as a Windows update.
Perhaps keyboards can begin to be manufactured with dual-color LED indicators in the CapsLock key as a visual cue to which Group is active; perhaps manufacturers would even begin to adopt a new name for the CapsLock key if/when this usage of multilingual keyboard layouts becomes more prevalent and widespread.
.

 

A more natural placement of the group3 selector is on PC keyboards the "Application/Menu" modifier key combined with a numeric key on the top row.

.
The AppsMenu/Context key is not a modifier key even though its function is otherwise actually nearly identical to that of the Alt/Menu key, except that it activates the context menu instead of the pulldown menus. Due to this fact, this implementation would also require a bit of new programming, it could also be done with AHK.
However, I see some flaws with this option.
1. it is not immediately intuitive and will be a bit more difficult to learn and remember
2. it is more difficult and awkward to type
3. it doesn't offer the visual cue of an LED light as an instant indicator of the currently active group
But these are not serious issues and this is certainly a viable option to be considered
.

 

The "Fn" key on PC keyboards is not really needed and should remain invisible to applications, but when it is present, Fn plus a key on the top row should do the same as F1..F12, it's just a hardware facility to be used on more compact keyboards to emulate missing keys which should not be used as a distinctive modifier in applications (As well Fn+Backspace can emulate Delete, Fn+Up can emulate PageUp, Fn+Down can emulate PageDown, Fn+Left can emulate Home, Fn+Right can emulate End, Fn+Space can emulate Insert).

.
Fn is not, and can not be used as an additional modifier on PC keyboards because it doesn't produce a scan code, and its behavior not standardized and completely up to the OEM.
.

 

In summary application should not depend on a distinctive presence of a "Fn" key. Even Fn+Alt can emulate the "Application/Menu" (or also Fn+AltGr, and so also Fn+Alt+Ctrl for compatibility, meaning that "Application/Menu" should never use a distinctive "Ctrl" state, but it is still allowed to have a distinctive Shift+"Aplication/Menu" which should not depend on CapsLock/ShiftLock state, and thus is equivalent to Shit+Fn+AltGr, or even Shift+Fn+Ctrl+Alt for the most reduced keyboards, which is difficult to type with another fifth key, unless it works in cunjunction of ShiftLock/Capslock emulated by pressing and releasing Shift twice, and that why the Capslock/ShiftLock state or Ctrl

and Alt state should not be distinctive for "Application/Menu")

.
.
What?!? The Apps/Menu key is not a modifier key. It can be used as such with a number and probably most other single keys on the keyboard. But the underlying hardware is not designed for this key to be used as a modifier and there will be multiple combinations which will fail because the underlying hardware required to recognize their simultaneous activation doesn't exist.
Don't believe me? Download a utility that reports scan codes and start testing the modifier key combinations listed in the previous paragraph plus the alphanumeric/symbol key to be modified and see how many work.
Although I admit I fail to understand what the purpose/point of that paragraph was and its importance to this topic.
.

 

So where can we place Group 3 (or higher) selector: on the "Fn" key if present (generally on compact keyboards), otherwise on its own key on non-compact keyboards that should not have or use the "Fn" key (they have dedicated F1..F12 keys, and/or complete cursor keys for Home, End, PgUp, PgDown, Insert, Del).

.
Sorry, but no. Again… Unless you're talking about not yet manufactured hardware which will be manufactured with these capabilities–but this effectively blocks out all current available hardware!
The Fn key is not modifier key, it's not even a real "key" on virtually all PC keyboards. It doesn't produce a scan code and ONLY works in conjunction with the keys as determined by the OEM which is completely unpredictable and not standardized at all.
Not to mention the fact that most non-integrated/embedded PC keyboards do not even have this key.
We need solutions applicable to widest range of hardware currently in use.
.
.

 

How to place the "numeric group" selector? NumLock seems to be appropriate (but it can also be emulated by Fn+B0 (before "1" on the top row, if it's not used for "0") or Fn+B10 (after key "9" on keyboards that place "0" before key "1" on the top row), and such emulation is not necessary on non compact keyboards featuring the "numlock" key in the numeric keypad.

 

But unlike the usual "Numlock" function of PC keyboards, the "numeric group" is not locking (and not even needed for complete PC keyboards with separate numeric keypads, as they all have also a complete set of cursor keys !).

 

If needed, the numeric group/Numlock can be emulated by "Fn" plus "+" (the last key of the top row).

.
.
I have no idea what this is about or its relevance, but: No… Fn can not be used for anything other than exactly what it was designed for. The physical hardware (wiring, controller chips & programming) do not exist; there is not software solution to this.

.
.
In regards to the original response to this message by Marcel:
While it is technically possible to map the left and right Option keys on a Mac separately, the critical underlying frameworks that support this distinction and pass it along to the running apps is no longer present and/or functional for many major releases of OS X/macOS. Which means that either support must be supplied by the applications themselves, or an add-on 3rd party plug-in tool. And there's a good chance that such a tool would be impossible to install with the restrictions imposed by the fairly recently implemented System Integrity security platform.
I may be some potential work around for this, but I believe it would most likely require an update to the underlying keyboard driver from Apple. And that is not something I would count on getting from Apple. But it's certainly not impossible. They clearly have the resources. It's just their willingness to cooperate and comply that always seems to be the issue.
,
I spent quite a long time attempting to get a Mac keyboard layout with separate mappings for left and right Option to behave and function according to its design and I never was able to do so. All of the most reliable and knowledgeable sources I could find and convince to interact with me each told me definitively that "No, that is not possible with OS X".
I would LOVE to be proven wrong, but I have given up hope at this point.
Although, I don't believe that such a mapping is actually absolutely necessary,
,
For one thing, CapsLock on Macs can function as a fully, unlimited group 2 with all the same modifier states as Group 1, whereas Windows can NOT do this. There are many restrictions in Windows regarding the CapsLock state (only single BMP codepoints per key, no dead keys, no ligatures, incomplete (or no) support for shift states above level 2…). None of this applies to Mac.
It is also possible as I mentioned above to create a separate mapping for Option+Ctrl (just as AltGr does in Windows) but without all the complications and conflicts inherent in Windows. The issue is that to activate this modifier state which is otherwise unused, the Ctrl key must also be pressed, and this is undesirable and awkward to type.
I personally found a solution using a 3rd party tool and continuing to use a previous version of OS X without the System Integrity. This tool is able to effectively simulate a concurrent activation of left Ctrl when I press the right Option key and so ultimately I did succeed in getting my keyboard layout to work, but not really. I had to revert the distinction between left and right Option and create the distinction with the Ctrl key. But of course this ultimately further limits the number of modifier states that are logistically feasible.
But it is still more than Windows which maxes out at 15 modifier states.
.
BTW, if you're interested in natively supported keyboard layouts for Windows which support the Japanese modifiers (and all 15 modifier states), check out KbdEdit. It is a 3rd party tool, but the keyboards it creates can run on any Windows machine and do not require the tool or any other additional software in order to fully function.
The extra modifiers will not be recognized and can not be used by apps. But, every app properly understands and receives any text you can enter in any state with your keyboard. It also has support for chained dead keys. It is not free, but I've found it more than worth the price and with the version I purchased I can create and distribute keyboards without any limits that can be used on any Windows machine.
But just reading through the documentation is very interesting and informative. The developer has managed to find or figure out a great deal about many very sparsely documented feature/frameworks of Windows and how to push Windows to the limits of its inherent capabilities.
.
Essentially KbdEdit is what MSKLC SHOULD be (but isn't even close)!

TracBot
May 9, 2019, 9:34 PM
Trac Comment 21 by —2018-10-17T15:34:50.337Z

CLDR 34 BRS closing item, move all upcoming → UNSCH

Priority

assess

Assignee

Mark Davis

Reporter

TracBot

Reviewer

None

Fix versions

None

Components

Labels

None

Phase

None

tracCreated

Jan 05, 2018, 9:26 PM

tracStatus

accepted

tracOwner

mark

tracReporter