* Move the following files from common/windows/cpp/include/ to
common/include/:
* keymanversion.h
* vkeys.h
* Move the following file from common/windows/cpp/ to common/cpp/:
* vkeys.cpp
* Move crc32.cpp,crc32.h into kmcmplib, as they are only used there.
* Remove unused ConvertUTF.c and ConvertUTF.h.
* Update references to the above files.
* Remove precompiled header refs from vkeys.cpp and change data type to
`char*` for types in vkeys.cpp (unless `USE_CHAR16_T` is defined), so
that it is more cross-platform accessible, update usages accordingly,
fixup project definitions accordingly.
* Remove unused define `KMN_KBP_EXPORTING` from kmcmplib/meson.build.
Fixes: #15565
Test-bot: skip
`boxArrays` had some optional chaining that was either not needed,
and/or was used in an inappropriate context, for example within the
iterable argument to a `for` statement, which would have caused an "not
iterable" error if it ever actually resolved to `undefined`.
This should have no material impact on the code, but helps to clarify
code readability.
Test-bot: skip
Add mappings for key to vkey + mod for .kvk and .keyman-touch-layout,
and clarify the key identifiers for .keyman-touch-layout within KMX+
format.
Update unit test fixture khmer_angkor.keyman_touch_layout to remove
dependency on .kmn (T_xxxx_yyyy -> U_xxxx_yyyy), as the relevant
VKDictionary will not be present, because the corresponding .kmn is not
compiled for the unit tests where the fixture is used.
Test-bot: skip
This comes out of a design philosophy review on what we include when we
embed OSK data into KMX.
We will now avoid embedding font name into the OSK (and hence .kmx)
altogether, and leave that metadata to the packaging data. Reasons:
1. The font information is specified in the .kps, so we have to do a
patchup on the .kmx during packaging if we want to embed the info
into the OSK.
2. The referenced font must be supplied separately anyway (via .kmp,
@font-face, or system supplied, etc), so including the font facename
in the keyboard is not really all that helpful.
3. Philosophically, the font is really a presentation level factor
(aside from displaymap considerations). Keeping it together with
future theming and styling choices, rather than the key layout data,
seems appropriate.
4. This makes fewer places where font data is referenced -- in fact, to
just one place: in the .kps/.kmp for LDML keyboards, which is great.
This also simplifies some aspects of the embed-osk-in-kmx work, removing
the need to patch the .kmx after the build, and eliminates the smelly
kmx-plus-osk-token.ts file.
A corresponding change has been made to the design document referenced
in #14857.
Test-bot: skip
jsonpp was being used only in a single unit test, and so this was a lot
of overhead and complexity for very little benefit. We may want to add
some more unit tests in the future for state_api.tests.cpp to do a
deep comparison of the state?
Test-bot: skip
Move U_25CC to a new CharacterConstants common enumeration.
Rewrite U_ key id conversion to check for invalid characters and report
to the keyboard author with warnings.
Co-authored-by: Eberhard Beilharz <ermshiperete@users.noreply.github.com>
Add mappings for key to vkey + mod for .kvk and .keyman-touch-layout,
and clarify the key identifiers for .keyman-touch-layout within KMX+
format.
Update unit test fixture khmer_angkor.keyman_touch_layout to remove
dependency on .kmn (T_xxxx_yyyy -> U_xxxx_yyyy), as the relevant
VKDictionary will not be present, because the corresponding .kmn is not
compiled for the unit tests where the fixture is used.
Test-bot: skip
This comes out of a design philosophy review on what we include when we
embed OSK data into KMX.
We will now avoid embedding font name into the OSK (and hence .kmx)
altogether, and leave that metadata to the packaging data. Reasons:
1. The font information is specified in the .kps, so we have to do a
patchup on the .kmx during packaging if we want to embed the info
into the OSK.
2. The referenced font must be supplied separately anyway (via .kmp,
@font-face, or system supplied, etc), so including the font facename
in the keyboard is not really all that helpful.
3. Philosophically, the font is really a presentation level factor
(aside from displaymap considerations). Keeping it together with
future theming and styling choices, rather than the key layout data,
seems appropriate.
4. This makes fewer places where font data is referenced -- in fact, to
just one place: in the .kps/.kmp for LDML keyboards, which is great.
This also simplifies some aspects of the embed-osk-in-kmx work, removing
the need to patch the .kmx after the build, and eliminates the smelly
kmx-plus-osk-token.ts file.
A corresponding change has been made to the design document referenced
in #14857.
Test-bot: skip
Add support for embedding .keyman-touch-layout into .kmx and complete
support and tests for embedding .kvk. Fixup a number of related
functions.
Add special-key-caps.ts to developer-utils -- in future this will become
the primary source for developer for these key caps, but this cannot be
done until Developer Server and Touch Layout Editor are updated with
Typescript in client code.
The boilerplate code for custom lexical models has never really been
tested. For use in a browser/worker context, we need to define
`exports`. The added unit test verifies that the model will build.
Test-bot: skip
