While it may be smarter to move to a different build system altogether,
it is also a *lot* more work. This was a fairly minor syntax refresh to
get nmake working with our existing Makefile system. This is now no
longer compatible with Borland make, so you will need to use `nmake` to
build.
The presence of NMAKE.md informs builds systems that nmake should be
used instead of make.
As the array length properties are unsigned integers, taking -1 from
them resulted in an integer overflow when the array was empty. A gotcha
with Delphi-style for loops!
Relates to #3620.
Allows keyboard developers to add a Caps Lock layer (called 'caps'),
which will be accessible through double-tap of Shift key, in an upcoming
PR.
Also adds test keyboards to exercise the functionality when it is
available.
Picked up during #5963 development.
If you ran `kmcomp <file.kmn> <out.js>`, compiler messages were passed
to a function with an incorrect signature, resulting in an exception.
This was a mode that was not widely used, which is why we haven't
picked it up earlier.
Relates to #3621.
Adds `readonly` group support and verifies that keyboards meet
constraints around usage of these groups.
(Note: fixes test_valid.kps and test.bat which seemed to have some
invalid tests?)
Relates to #3621.
Add support for `&layerChanged` system store. This store is set to `1`
before a `begin postKeystroke`, if the keystroke it follows resulted in
a layer change, either programatically through a keyboard rule, or
through a `nextlayer` property of the touched key.
Relates to #3621.
This adds basic compiler support for the `begin newContext` and
`begin postKeystroke` statements, along with the corresponding `gn` and
`gpk` entry points in the compiled JavaScript keyboard.
TODO: `readonly` semantics, usage constraints, `&layerChanged`.
Fixes#5779.
Fixes#5731 (I believe mitigation is sufficient to close this issue).
A variety of interrelated font and font size display issues resolved:
1. KVK font was not applied early enough for size calculations, which
meant that we were calculating font scaling per key based on a
default font when transforming from the KVK data for desktop devices
(defaultLayout.ts)
2. Font scaling for non-default layers was calculated when elements were
not visible and had no size information, giving incorrect values. To
resolve this, font scaling is now calculated when a layer is made
visible, which had performance impacts; resolved by reducing
unnecessary `layer.refreshLayout()` calls; see performance point 1
below (oskView.ts:layerChangeHandler())
3. `getViewportScale()` would return an incorrect scaled value when
emulating touch devices on a desktop browser (kmwutils.ts)
4. After switching keyboards, the device-specific scaling factor was not
maintained (oskView.ts:refreshLayout())
Related performance improvements:
1. Multiple calls to `layer.refreshLayout()` in `refreshLayout()` have
been eliminated, and only the currently visible layer is now
refreshed. This dramatically reduces the number of calls to
`getIdealFontSize()` which was the primary concern of #5731.
(visualKeyboards.ts)
2. Unnecessary use of `innerHTML` replaced with `innerText`
(oskBaseKey.ts)
Minor Keyman Developer performance improvement:
1. The web debugger no longer recalculates the OSK twice (test.js)
