Relates to #5816.
Moves folders under common/core/web to common/web:
* input-processor -> common/web/input-processor
* keyboard-processor -> common/web/keyboard-processor
* tools/recorder -> common/web/recorder
* tools/sentry-manager -> common/web/sentry-manager
* utils -> common/web/utils
Updates scripts and configuration to point to new folders.
This starts the reorg required for splitting the lm worker into its own
module. Tests are still not working. But builds are going.
Some decisions to be made around the final path for wrapping of the
code. I think it may be possible to do something a whole lot more
elegant by moving the wrapping process into the KMW build and leaving
the LM Worker output as a pure tsc output -- given only KMW wants the
wrapped worker anyway (tests aside). The actual wrapping code could
still be in the lm-worker folder.
Fixes#6320.
Part 1 of moving from lerna to a simpler, maintained monorepo solution,
using TypeScript Projects and NPM Workspaces.
There is more work to be done here. At this point, KeymanWeb builds and
runs without errors, but the built file is substantially different,
mostly in include order.
Using TypeScript Projects, we move away from the need to run build
scripts in various locations for almost all the Typescript modules.
TODO: Embedded versions and tests have not been verified.
TODO: developer/server is not yet verified.
TODO: developer/js (needs a rename!) is not yet verified.
TODO: Currently, the predictive-text folder needs refactoring to move
the construction of the worker wrapper out of the Predictive Text build
and into the final assembly of keymanweb.js (as it should be valid to
run it as a separate .js anyway).
TODO: Most of the `<reference>` paths need to be re-verified. Ideally
there should be no references outside the current module for any given
.ts.
TODO: The embedded vs browser vs node (headless) builds should be tidied
up for consistency so that it's obvious what depends on what. This is
currently messiest in the predictive-text folder, where the output names
diverge from the filenames and the various files are mixed in the same
folder (as evidenced by the exclusions listed in each tsconfig.json).
TODO: `npm install` should be removed from most build scripts and
instead `npm ci` (#6196) should be run only once from the top-level
folder for any given build. I've had eliminated side-effects from the
`install` action for npm, which makes it easier to reason about state.
TODO: verify_npm_setup and related functions can probably be eliminated.
TODO: most of the build scripts should be largely eliminated for web.
TODO: several ts projects use inconsistent output folders.
TODO: it may be possible to generate a .d.ts for models/types so that
we can use a consistent reference for those as well.
TODO: build.sh, tsconfig.json should always be in the module's top-level
folder, not in a subfolder such as src (e.g. see input-processor/src,
keyboard-processor/src, web/source).
TODO: resources/web-environment should be in common/web.
TODO: other js node_modules imports should be wrapped like es6-shim.
TODO: fix up the publish code for npm modules
TODO: eliminate version numbers from package.json if possible?
Whew, that's most of the stuff I noticed!
Fixes#6455.
This involved adding an extra hint to the data passed into the lexical
model layer, being the CasingForm that the current layer wants to use.
Given there are several entry points to the lexical model layer, this
meant a few places where we needed to check the current layer.
I refactored the very long function `InputProcessor.processKeyEvent` to
extract out the `buildAlternates` function. There should be no
functional changes to the `buildAlternates` code. But it makes
`processKeyEvent` significantly easier to read.
Fixes#6455.
This involved adding an extra hint to the data passed into the lexical
model layer, being the CasingForm that the current layer wants to use.
Given there are several entry points to the lexical model layer, this
meant a few places where we needed to check the current layer.
I refactored the very long function `InputProcessor.processKeyEvent` to
extract out the `buildAlternates` function. There should be no
functional changes to the `buildAlternates` code. But it makes
`processKeyEvent` significantly easier to read.
This is a follow-up for #6331. We still did not have enough detail to
be able to trace the root cause of the load errors. This adds a little
more diagnostics.
While this was done in code as a global override, probably following
Apple stylistic changes, it is better to leave this to the keyboard
developer to decide on.
Adjusts the dimensions to use pixel boundaries to prevent antialiasing
for some of the key preview and longpress popups, and adjusts horizontal
positioning of key preview to center more precisely, for iOS.
Observed while debugging another issue on iOS. The
VisualKeyboard.waitForFonts function sets up a busy timer to wait for
font loading. This functionality is not even needed on the iOS app,
because it's really only used for the touch alias elements.
However, it was being called, potentially multiple times, leading to the
timer never being removed. On Android, the timer was correctly removed.
This aligns the iOS code path with the Android code path.
Fixes#5942.
The touch alias element position was not consistent across all browsers,
leading to misalignment in some situations. Identified missing CSS to
make the positioning consistent, as far as I can tell, which led to the
additional benefit of reducing the per-browser special cases.
Fixes the following crash noted when testing on keymanweb.com, focusing
during the load process on a slow network.
```
helpers.ts:111 Uncaught TypeError: Cannot read properties of null (reading 'vkbd')
at g.pageFocusHandler (keymanweb.ts:125:44)
at sentryWrapped (helpers.ts:87:17)
```
Fixes#5929.
Fixes#6381.
This fixes four separate issues with the longpress popups and key
previews:
1. The key preview was offset by a couple of pixels (unreported issue).
2. The background 'shim' did not cover the key caps, which caused them
to look startlingly white when the rest of the background greyed
down (#5929).
3. The popup menu was incorrectly wrapping to two rows due to sizing
model mismatches (#6381).
4. The popup menu would be realigned incorrectly for the in-app
keyboard, when moving it to keep it in the keyboard area (#5929).
Fixes#6364.
Removes `&layerChanged` and adds `&newLayer` and `&oldLayer` system
stores with the additional nuances around values as described in #6364.
When embedding the On Screen Keyboard into a page, the calculation for
the bounding rectangle only took into account the first offsetParent,
which meant it would get the offset incorrect when there were multiple
layers of offsetParents.
Once I changed to using getAbsoluteX / getAbsoluteY, this also corrects
for scroll with window.pageOffsetY, so we can eliminate that special
case for fixed positioning.
This was observable in the Web Developer test window, where interaction
with the bottom row of the keyboard in touch mode was not working
correctly, in 15.0.210-beta.
The Caps Lock change I made in the previous commit broke
desktop Caps Lock handling. The fix was a little more
convoluted. Turns out that _UpdateVKShift is also pretty
crufty. I simplified it, removing dead code.
Fixes#5964.
It seems that the test for subkey position was incorrect when the
document had been scrolled. Removing the test for `fixed` positioning
resolves the issue.
This fixes an issue that arises when loading the Keyman Developer Server
home page and there are registered keyboards, but no keyboards active.
The floating osk view would throw an exception because it would attempt
to set the title of the view from the active keyboard, which is `null`.
