This feature would help with many CBC user problems. The overlay should always represent the active keyboard.

#CBC-RS/TC-watchlist

Here is a recent thread that illustrates the user's confusion when the keyboard language is incorrect. If the proper overlay was available, it would be possible to show the user what was happening.
https://productforums.google.com/forum/#!topic/chromebook-central/pUwDEjgRn40;context-place=forum/chromebook-central

Looks like we're missing a few of the shortcuts for key combos when using AltGr

afakhry@ could you have a look at adding those?

kpschoedel, where do I get a list of these AltGr specific characters?

#6 I think ideally they would be generated from the active layout (and probably cached), as it is possible for an extension to enable xkb layouts that are not accessible in the base system (see e.g github.com/google/extra-keyboards-for-chrome-os). Ozone makes this pretty simple; for each overlay key position |ui::DomCode code| call
  KeyboardLayoutEngineManager::GetKeyboardLayoutEngine()->Lookup(code, flags, &key, &dummy_windows_code)
where |flags| is the ui::EventFlags for the state you're interested in, e.g. (EF_ALTGR_DOWN|EF_SHIFT_DOWN). Then inspect the |ui::DomKey key| result, i.e. key.IsCharacter() for a Unicode character and key.IsDeadKey() for a combining key.

Unfortunately there is still one platform using X11 (nyan, waiting on some GPU driver work) and the X11 equivalent of that takes some more code. The steps are, roughly,
- use |ui::KeycodeConverter::DomCodeToNativeKeycode()| to get the X11 location keycode;
- get the X11 flags corresponding to the ui::EventFlags; there's code in events_x.cc |UpdateX11EventFlags()|for this but it's currently private;
- build an |XKeyEvent| with the X11 keycode and flags;
- call |ui::GetDomKeyFromXEvent()| on the X11 event.

 Issue 628934  has been merged into this issue.

Any progress on this? It's been assigned for a year and a half.

Now there are new and apparently-undocumented keyboard layouts (such as "US International (PC)"), and having a working keyboard overlay for the international keys would help to distinguish between them.

Wikipedia has a nice image of what it would likely look like:

https://en.wikipedia.org/wiki/AltGr_key#US-International

Please read #9 more carefully.

"US International" is a standard layout name. "US International (PC)" and "US Extended" are not.

More generally, Wikipedia is not an adequate substitute for product documentation.

The keyboard overlay is deprecated, and will be replaced by a new keyboard shortcut helper very soon.

Is there a tracking bug for the new keyboard shortcut helper?

Will it address the use-case of viewing specific input methods, or just the built-in keyboard shortcuts?

Yes, it will show the correct shortcuts based on the currently selected input method. Tracking bug is issue 768932.

It seems we do not have any EF_ALTGR_DOWN shortcuts anymore?

#11 Although some countries have formal layout standards (e.g. BS 4822 in the UK), the US doesn't. “US International” is the name of a keyboard layout on Windows, which ChromeOS's “US International (PC)” imitates as far as possible. (Discrepancies can be filed as bugs.)

#15 AltGr should never be used explicitly in any shortcuts. Some layouts have no AltGr.

> Tracking bug is issue 768932.

It seems I don't have permission to view that. Is there a reason it needs to be kept inaccessible?

> it will show the correct shortcuts based on the currently selected input method.

That doesn't address the underlying use-case of this bug, which is some way to view the non-shortcut behavior of the current layout, such as 3rd-level shifted characters and dead keys.

Since I can't determine whether the new helper is intended to show the non-shortcut behaviors, I've filed https://crbug.com/811900 to focus on the missing documentation. (If all of the requested documentation will be provided by the new helper, feel free to dup it to 768932 if it is made publicly viewable.)

No, I don't think that was never a goal of the shortcut helper.