feat(developer): cleanup touch layout files on load and save 🙊 #6917
Conversation
keymanapp-test-bot
bot
added
the
user-test-missing
User Test ResultsTest specification and instructions User tests are not required Test Artifacts
|
mcdurdin
changed the title
mcdurdin
changed the base branch from
feat/developer/touch-layout-editor-flick-and-multitap
to
feat/developer/touch-layout-compiler-flick-and-multitap
mcdurdin
force-pushed
the
feat/developer/touch-layout-schema-high-quality
branch
from
8182dad to
1cb0444
Compare
mcdurdin
requested review from
rc-swag,
sgschantz and
ermshiperete
as code owners
Improves the .keyman-touch-layout clean schema and adds additional cleanup during load and save in the Touch Layout Editor. The compiler already does transforms for the relevant fields to the formats that KeymanWeb is expecting (in particular, width, pad to string). This is preparation for adding hint data to the format as well.
mcdurdin
force-pushed
the
feat/developer/touch-layout-compiler-flick-and-multitap
branch
from
5bf1235 to
60dabb5
Compare
mcdurdin
force-pushed
the
feat/developer/touch-layout-schema-high-quality
branch
from
1cb0444 to
51a94a1
Compare
| "anyOf": [ | ||
| {"required": ["id"]}, | ||
| {"required": ["sp"]}, | ||
| {"required": ["sk"]}, | ||
| {"required": ["flick"]}, | ||
| {"required": ["multitap"]} | ||
| ], |
There was a problem hiding this comment.
Are there cases where we may wish to support an id-less key that has subkeys, flicks, or multitaps?
Granted, I'm not super-great with schemas, but my impression of this part of the spec appears to permit such a case.
I know we permit id-less keys with sp properties - such as for a 'blank' space for row padding, so no complaints on that one.
There was a problem hiding this comment.
Your reading is correct.
I guess it seems unlikely but not impossible? A 'special characters' key which has no default behaviour but does have flicks or longpress -- where the keyboard author doesn't want it to be triggered by accident? Like I say, unlikely but probably no really good reason to restrict the schema.
| return true; | ||
| }; | ||
|
|
||
| let cleanupNumericField = function(obj, prop) { |
There was a problem hiding this comment.
I don't see a case where this can return false - only true. Granted, it is part of a boolean-logic condition chain in a different function, but it still strikes me a bit odd.
There was a problem hiding this comment.
Given none of the cleanup* functions are returning false I could make them conceptually void functions. BUt not sure if it makes any difference? 😄
keymanapp-test-bot
bot
removed
the
user-test-missing
mcdurdin
merged commit ca47fce
into
feat/developer/touch-layout-compiler-flick-and-multitap
Improves the .keyman-touch-layout clean schema and adds additional cleanup during load and save in the Touch Layout Editor.
The compiler already does transforms for the relevant fields to the formats that KeymanWeb is expecting (in particular, width, pad to string).
This is preparation for adding hint data to the format as well.
@keymanapp-test-bot skip (automated tests will cover this with compiler regression testing)