Skip to content

feat(developer): add 'default' property for longpress keys#9432

Merged
mcdurdin merged 2 commits intomasterfrom
feat/developer/9430-default-long-press
Aug 9, 2023
Merged

feat(developer): add 'default' property for longpress keys#9432
mcdurdin merged 2 commits intomasterfrom
feat/developer/9430-default-long-press

Conversation

@mcdurdin
Copy link
Copy Markdown
Member

@mcdurdin mcdurdin commented Aug 8, 2023

Fixes #9430.

Adds a 'default' property to subkeys, only used by longpress-type subkeys:

  • Added property to schema and readers/writers
  • Added property to touch layout validator
  • Added editor for property to layout builder

User Testing

In Keyman Developer, open the touch layout tab in a keyboard. Select a key and create a set of longpress keys.

  • TEST_DEFAULT_PROPERTY: Select a subkey, and tick the 'Is Default' property. The border of the subkey should be bolded to indicate that it is default. Go to Code view and verify that the property "default":true is correctly set for the subkey.
  • TEST_RESET_DEFAULT: Select the same subkey, and untick the 'Is Default' property on that key. The subkey should lose its bold border. Go to Code view and verify that the property "default" is correctly removed for the subkey.
  • TEST_RESET_ALL: Tick the 'Is Default' property for one subkey. Then, select another subkey under the same key, and tick the 'Is Default' property on that key. The original 'default' subkey should lose its bold border, and the new subkey should have a bolded border. Go to Code view and verify that the property "default":true is correctly set for the new subkey, and removed for the old subkey.

@mcdurdin
feat(developer): add 'default' property for longpress keys
c02f5ab 
Fixes #9430.

Adds a 'default' property to subkeys, only used by longpress-type
subkeys:

* Added property to schema and readers/writers
* Added property to touch layout validator
* Added editor for property to layout builder
@keymanapp-test-bot keymanapp-test-bot bot added has-user-test user-test-required User tests have not been completed labels Aug 8, 2023
@keymanapp-test-bot
Copy link
Copy Markdown

keymanapp-test-bot bot commented Aug 8, 2023 •
edited
Loading

User Test Results

Test specification and instructions

  • ✅ TEST_DEFAULT_PROPERTY (PASSED): Tested with the attached PR build (keyman 17.0.157-alpha-test-9432) in Windows 11 OS (VM) and here is my observation: 1. Verified that after enabling 'Is Default' property for a subkey, the border of the subkey was bold. Moved to the Code view and verified that the property 'default:true' is correctly set for the subkey. (notes)
  • ✅ TEST_RESET_DEFAULT (PASSED): 1. Verified that after disabling 'Is Default' property for the same subkey, the subkey lost its bold border. 2. Moved to the Code view and verified that the property was removed from the subkey. (notes)
  • ✅ TEST_RESET_ALL (PASSED): 1. Verified that the original 'default' subkey lost its bold border and the new subkey is having the bold border. 2. Moved to the code view and verified that the property 'default:true' is correctly set to the new subkey and it has been removed for the old subkey. (notes)

@keymanapp-test-bot keymanapp-test-bot bot added this to the A17S19 milestone Aug 8, 2023
@bharanidharanj
Copy link
Copy Markdown

bharanidharanj commented Aug 8, 2023

Test Results

  • TEST_DEFAULT_PROPERTY (PASSED): Tested with the attached PR build (keyman 17.0.157-alpha-test-9432) in Windows 11 OS (VM) and here is my observation: 1. Verified that after enabling 'Is Default' property for a subkey, the border of the subkey was bold. Moved to the Code view and verified that the property 'default:true' is correctly set for the subkey.

  • TEST_RESET_DEFAULT (PASSED): 1. Verified that after disabling 'Is Default' property for the same subkey, the subkey lost its bold border. 2. Moved to the Code view and verified that the property was removed from the subkey.

  • TEST_RESET_ALL (PASSED): 1. Verified that the original 'default' subkey lost its bold border and the new subkey is having the bold border. 2. Moved to the code view and verified that the property 'default:true' is correctly set to the new subkey and it has been removed for the old subkey.

@keymanapp-test-bot keymanapp-test-bot bot removed the user-test-required User tests have not been completed label Aug 8, 2023
darcywong00
darcywong00 reviewed Aug 8, 2023
View reviewed changes
common/schemas/keyman-touch-layout/README.md Outdated
: Boolean. Defaults to `false`. If true, this will be the default key when the
user longpresses the base key without moving their finger. Only one subkey
should be default; if multiple subkeys have the default field set, then
behaviour is undefined.
Copy link
Copy Markdown
Contributor

@darcywong00 darcywong00 Aug 8, 2023

Choose a reason for hiding this comment

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

It might be nice to have the "cancel" behavior you wrote in #8519 documented somewhere

  • Given that cancel is not the preferred default action for a longpress, the user can cancel the longpress default by sliding outside the 'acceptance' area -- e.g. south of the key cap, which would then unhighlight the default and indicate visually that no output would occur when they release their finger.

darcywong00
darcywong00 reviewed Aug 8, 2023
View reviewed changes
mcdurdin
mcdurdin commented Aug 9, 2023
View reviewed changes
@mcdurdin mcdurdin merged commit 22f7bdc into master Aug 9, 2023
@mcdurdin mcdurdin deleted the feat/developer/9430-default-long-press branch August 9, 2023 08:32
@keyman-server
Copy link
Copy Markdown
Collaborator

keyman-server commented Aug 9, 2023

Changes in this pull request will be available for download in Keyman version 17.0.158-alpha

@MayuraVerma
Copy link
Copy Markdown
Contributor

MayuraVerma commented Aug 20, 2023 •
edited
Loading

I am using iOS, keyman 17.0.161 and a keyman with longpress default is set true. Still longspress is not pickup the default key.
I am using store(&VERSION) '16.0'

store(&VERSION) '17.0' developer throws error

Am I missing something

@darcywong00
Copy link
Copy Markdown
Contributor

darcywong00 commented Aug 21, 2023

@MayuraVerma - This has only been implemented in Keyman Developer so far. The mobile apps will still need to implement handling default subkeys (likely post-17.0)

@jahorton
Copy link
Copy Markdown
Contributor

jahorton commented Aug 21, 2023 •
edited
Loading

store(&VERSION) '17.0' developer throws error

I'm a bit curious about that point.

The mobile apps will still need to implement handling default subkeys likely post-17.0

Likely before 17.0 release, at least on iOS. Android is, admittedly, trickier for this.

@MayuraVerma
Copy link
Copy Markdown
Contributor

MayuraVerma commented Aug 21, 2023

@MayuraVerma - This has only been implemented in Keyman Developer so far. The mobile apps will still need to implement handling default subkeys (likely post-17.0)

While gestures are implemented in v17, if this gesture, longpress+release is also implemented, it would be great.

@jahorton jahorton mentioned this pull request Aug 21, 2023
Merged
@mcdurdin
Copy link
Copy Markdown
Member Author

mcdurdin commented Sep 4, 2023

store(&VERSION) '17.0' developer throws error

The &VERSION statement is really related to the minimum version required to support functionality in the .kmn keyboard (without reference to the visual keyboard, touch keyboard). It is usually optional -- Keyman Developer can figure out the minimum version required. So far, there's no functionality in the .kmn format that requires 17.0, so the maximum version number available is 16.0.

But I plan to add 17.0 to the VERSION statement because flick and multitap gestures are only going to be available in 17.0+. And because that information is stored in the touch keyboard, I need to check and see if Keyman Developer is able to determine it automatically.

@mcdurdin mcdurdin mentioned this pull request Sep 4, 2023
Closed
@darcywong00 darcywong00 mentioned this pull request May 15, 2024
Closed
@jahorton jahorton linked an issue Apr 4, 2025 that may be closed by this pull request
feat(web): default subkey specification #4313
Closed
@jahorton jahorton mentioned this pull request Apr 4, 2025
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@darcywong00 darcywong00 darcywong00 left review comments

@jahorton jahorton jahorton approved these changes

Assignees

No one assigned

Labels

common/web/ common/ developer/ide/ developer/ feat has-user-test

Projects

None yet

Milestone

A17S19

Development

Successfully merging this pull request may close these issues.

feat(developer): define long-press default key 🐵 feat(web): default subkey specification

6 participants

@mcdurdin @bharanidharanj @keyman-server @MayuraVerma @darcywong00 @jahorton