Skip to content

feat(web): add osk.gestureParams for better gesture-config persistence#12176

Merged
jahorton merged 1 commit intomasterfrom
feat/web/better-gesture-config-persistence
Aug 14, 2024
Merged

feat(web): add osk.gestureParams for better gesture-config persistence#12176
jahorton merged 1 commit intomasterfrom
feat/web/better-gesture-config-persistence

Conversation

@jahorton
Copy link
Copy Markdown
Contributor

@jahorton jahorton commented Aug 14, 2024

Adds a more 'stable' internal API point (keyman.osk.gestureParams) for configuring gesture parameterization settings. I'm not convinced it's the long-term best solution as the "true" API point, but I think that even if not, it's likely to be quite usable by whatever we decide on making that API point.

With this changeset, the gesture parameters only need to be adjusted once; the new setting will persist for the lifetime of the OSK, even across keyboard swaps.

Example:

keyman.osk.gestureParams.longpress.waitLength = 5000 // sets the longpress delay to 5 sec

@keymanapp-test-bot skip

@jahorton jahorton requested a review from ermshiperete as a code owner August 14, 2024 04:09
@keymanapp-test-bot keymanapp-test-bot bot added this to the A18S8 milestone Aug 14, 2024
@jahorton jahorton requested a review from darcywong00 August 14, 2024 04:09
@jahorton jahorton requested a review from mcdurdin August 14, 2024 04:11
Copy link
Copy Markdown
Contributor

@darcywong00 darcywong00 left a comment

Choose a reason for hiding this comment

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

lgtm

Base automatically changed from fix/web/longpress-configurability to master August 14, 2024 04:40
@mcdurdin
Copy link
Copy Markdown
Member

When do the parameters take effect? Is the update instant? This works for this type of parameter but there may be others where it would be better to have a function approach rather than a property approach particularly if 'batching' many options.

@jahorton
Copy link
Copy Markdown
Contributor Author

jahorton commented Aug 14, 2024

When do the parameters take effect? Is the update instant? This works for this type of parameter but there may be others where it would be better to have a function approach rather than a property approach particularly if 'batching' many options.

The update is instantly applied for any gestures not currently active and for future instances of the same gesture. For any configurable aspect of a gesture, the gesture specs refer to it through the same instance returned by this property.

(For a longpress, the duration value is used to create the timer for a longpress gesture component when a key is first touched. It doesn't look up the value again afterward for that touch.)

There's no "rebuilding" of the models involved here; only the thing "pointed to" / "referenced" is changed. We could change fields on the object and its subobjects in a batch the same way we do for a single copy; that'd be fine here. I made sure to design it this way during 17.0 gesture work.

@jahorton jahorton merged commit e2b5d82 into master Aug 14, 2024
@jahorton jahorton deleted the feat/web/better-gesture-config-persistence branch August 14, 2024 08:21
@mcdurdin
Copy link
Copy Markdown
Member

Don't forget to update the API documentation

@keyman-server
Copy link
Copy Markdown
Collaborator

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

@jahorton
Copy link
Copy Markdown
Contributor Author

Don't forget to update the API documentation

Are you saying to make it official API on help.keyman.com?

Wasn't sure if we wanted this to be internal and wait to design something better or if we wanted to go ahead and make it external.

@mcdurdin
Copy link
Copy Markdown
Member

Don't forget to update the API documentation

Are you saying to make it official API on help.keyman.com?

Wasn't sure if we wanted this to be internal and wait to design something better or if we wanted to go ahead and make it external.

I don't think we should be writing undocumented internal APIs any more. We are trying to get better at doing APIs and each undocumented API we add just makes it worse. So, we need to document it as an API, whether that is as a public API on help.keyman.com or a private API on the wiki I am less sure about.

@jahorton
Copy link
Copy Markdown
Contributor Author

I don't think we should be writing undocumented internal APIs any more. We are trying to get better at doing APIs and each undocumented API we add just makes it worse. So, we need to document it as an API, whether that is as a public API on help.keyman.com or a private API on the wiki I am less sure about.

I have added a new wiki page: https://github.com/keymanapp/keyman/wiki/Mobile-app-%E2%80%90-app-webview-API

It's linked by the main Wiki index at the bottom of the first section ("API documentation").

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.

4 participants