Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor(developer): .keyboard_info examples should use keys as a string 🎺 #9711

Conversation

mcdurdin
Copy link
Member

@mcdurdin mcdurdin commented Oct 8, 2023

Fixes #9708.

Matches the kmp.json format of keys string in the .keyboard_info schema and compiler, in order to reduce the number of formats we are working with. This same format may be used elsewhere in Keyman schemas in the future for sets of keys, for example, I hope we can use it in regression tests.

@keymanapp-test-bot skip

Fixes #9708.

Matches the kmp.json format of keys string in the .keyboard_info schema
and compiler, in order to reduce the number of formats we are working
with. This same format may be used elsewhere in Keyman schemas in the
future for sets of keys, for example, I hope we can use it in regression
tests.
@keymanapp-test-bot
Copy link

keymanapp-test-bot bot commented Oct 8, 2023

@keymanapp-test-bot keymanapp-test-bot bot changed the title refactor(developer): .keyboard_info examples should use keys as a string refactor(developer): .keyboard_info examples should use keys as a string 🎺 Oct 8, 2023
@keymanapp-test-bot keymanapp-test-bot bot added this to the A17S23 milestone Oct 8, 2023
@mcdurdin mcdurdin linked an issue Oct 8, 2023 that may be closed by this pull request
@mcdurdin mcdurdin marked this pull request as ready for review October 8, 2023 22:06
{ "key": "E" },
{ "key": "r" }
],
"keys": "x j m E r",
"text": "\u1781\u17D2\u1798\u17C2\u179A",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this being reverted from #9621? Also, how would this look in regard to #9671, and how would the issue be affected?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I opted to go with the much shorter .kps format and not have two different formats for key strings.

For #9671, I don't really have a good answer, not sure what useful test to put in for that at present. The pattern is deliberately open-ended because we don't know what the key caps will have. Only four substrings have meaning:

  • : key delimiter, e.g. x j m shift+e r
  • +: modifier joiner, e.g. shift+ralt+z, or shift+3.
  • space: longhand for spacebar, e.g. k a space m r, and
  • plus: + key, made available to avoid confusion with specs like shift+plus, which would otherwise be shift++.

These are not intended to be used to generate key events -- they are supposed to be human readable keys.

Base automatically changed from feat/developer/9478-welcome-file-property to epic/package-metadata October 11, 2023 00:18
@mcdurdin mcdurdin merged commit d217b46 into epic/package-metadata Oct 11, 2023
3 checks passed
@mcdurdin mcdurdin deleted the refactor/developer/9708-keyboard_info-example-keys-as-string branch October 11, 2023 00:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

refactor(common): keyboard_info schema: reduce key sequences to string
3 participants