feat: Handle Numeric AccessKey

[workgroupengineering]

What does the pull request do?

Handle Numeric AccessKey

What is the current behavior?

Access Key like <Label Content="_1 Oprions"/> does not work

What is the updated/expected behavior with this PR?

Access Key like <Label Content="_1 Oprions"/> work with Numeric Key, does not with Numpad Key

How was the solution implemented (if it's not obvious)?

Using Platform.KeyGestureFormatInfo.FormatKey insteand of Key.ToString()

Checklist

• Added unit tests (if possible)?
• Added XML documentation to any related classes?
• Consider submitting a PR to https://github.com/AvaloniaUI/avalonia-docs with user documentation

Breaking changes

Obsoletions / Deprecations

Fixed issues

Fixes #15957

[avaloniaui-bot]

You can test this PR using the following package version. 11.2.999-cibuild0049170-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[avaloniaui-bot]

You can test this PR using the following package version. 11.2.999-cibuild0049179-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[IanRawley]

I don't have a lot of experience with the AccessKey side of things, so I can't comment on why it's done the way it is but I personally feel it would probably be a better idea to register the Key rather than Char in the AccessKeyHandler dictionary and parse the Key once on registration rather than trying to deal with synonyms every time a key is pressed. While this probably handles the numeric AccessKey situation, I suspect it doesn't deal with the non-English AccessKey situation well.

[stevemonaco]

@IanRawley Changing from char to Key would require a breaking change in AccessText.AccessKey, at least for consistency:

Avalonia/src/Avalonia.Controls/Primitives/AccessText.cs

Lines 45 to 49 in 143399f

	public char AccessKey
	{
	get;
	private set;
	}

The i18n is probably an issue, too, as you pointed out.

[workgroupengineering]

I don't have a lot of experience with the AccessKey side of things, so I can't comment on why it's done the way it is but I personally feel it would probably be a better idea to register the Key rather than Char in the AccessKeyHandler dictionary and parse the Key once on registration rather than trying to deal with synonyms every time a key is pressed. While this probably handles the numeric AccessKey situation, I suspect it doesn't deal with the non-English AccessKey situation well.

I chose KeyGestureFormatInfo because it is extensible.

Avalonia/src/Avalonia.Base/Input/Platform/KeyGestureFormatInfo.cs

Line 20 in 143399f

public sealed class KeyGestureFormatInfo(IReadOnlyDictionary<Key, string>? platformKeyOverrides = null,

In the future we could add in AppBuilder which allows you to configure KeyGestureFormatInfo to solve the problem you expose.

[IanRawley]

@IanRawley Changing from char to Key would require a breaking change in AccessText.AccessKey, at least for consistency:

Avalonia/src/Avalonia.Controls/Primitives/AccessText.cs

Lines 45 to 49 in 143399f

	public char AccessKey
	{
	get;
	private set;
	}

The i18n is probably an issue, too, as you pointed out.

Yeah, that's the bit I wasn't aware of. I was just looking at the AccessKeyHandler. If AccessText is pulling the char out of the dictionary, then keeping the dictionary as a char makes sense. If the AccessText is what's feeding the char to AccessKeyHandler to populate the dictionary, then the dictionary could become a Key without breaking anything, but is also less likely to solve all the other issues non-English access keys are likely to cause. I'm specifically thinking Japanese myself, as I have some experience with Japanese keyboards, but not enough with Japanese apps to know if developers are likely to use access keys with Hiragana or Katakana characters.

[avaloniaui-bot]

You can test this PR using the following package version. 11.2.999-cibuild0050218-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[avaloniaui-bot]

You can test this PR using the following package version. 11.2.999-cibuild0050230-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[avaloniaui-bot]

You can test this PR using the following package version. 11.2.999-cibuild0050505-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[avaloniaui-bot]

You can test this PR using the following package version. 11.2.999-cibuild0051029-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[avaloniaui-bot]

You can test this PR using the following package version. 11.2.999-cibuild0051447-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[workgroupengineering]

should I make any other changes?

[stevemonaco]

We may want to also add || !MainMenu.IsVisible here or combine with pattern matching. If it's not visible, then we currently get the same "sticky" behavior as the original issue where alt is released, but the access keys are still underlined.

[avaloniaui-bot]

You can test this PR using the following package version. 11.2.999-cibuild0051910-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]