Fixes#4490.
Fixes#4435.
There are three parts to this:
1. Ensure that transient language profiles associated with a disabled
keyboard are enumerated correctly
2. Stop trusting `LocaleNameToLCID` when it returns a transient language
id, as it sometimes reports out-of-date values. We don't need to
trust it in these cases anyway, because we have already collected the
relevant transient language data from Win8Languages.
3. Finally, setting the profile GUID to `GUID_NULL` is simply tidyup,
which does not have impact on the running code currently but makes
state consistent.
I believe that part 2 fixes#4435 because the symptoms are identical.
But as I am unable to repro that particular issue on my machine thus
far, that is an assumption. Hopefully we can get a good test result from
@MakaraSok.
Fixes#4409.
If a user attempts to install an older version of Keyman, they need to
be able to choose to install the older version, and not the newer one
offered to them from online. However, the selector was hidden in the
Install Options dialog, even when it should have been accessible.
Fixes#4557.
When focus changes, we need to re-run `_PreserveAltKeys` as settings may
have changed, meaning we have to preserve a different set of keys. I
also made the `_PreserveAltKeys` function idempotent so that we don't
have to worry about cleanup before calling it -- by calling the cleanup
function internally instead.
Fixes#4591.
I fixed incxstr in 4 places:
1. Common/Core: kmx_xstring.cpp
2. Engine: xstring.cpp
3. Test project importkeyboard importkeyboard.cpp
4. Test project m-to-p m-to-p.cpp
I updated mcompile to remove its own copy of incxstr (identical to that
in xstring.cpp) to reduce WETness but opted not to do so for the test
apps, which are pretty much throwaway anyway.
I note that there is more work we could do here; we need to check every
character as we increment so we don't miss a `U+0000` end of string with
malformed data. But I would like to tackle that as a separate job at
some point in the future after Core integration.
I discovered this while working on #4586. The code in question was
updating `*puKey` and then trying to dereference the array on the basis
of its new value, which (a) would give the wrong result, and (b) could
be reading off the end of the array (although not crashing it seems),
e.g. for `"` -> `VK_QUOTE`, which has a value of `0xDE`.
I am guessing that the reason we have not seen any bug reports on this
is that the keystroke handler falls back to an alternate code path, so
in the vast majority of cases, keyboards would continue to work
correctly. Furthermore, the test was just for truthiness of the `BOOL`
so probably at least 50% of the time we'd have been okay anyway. Or
something. Anyway, I reckon this is better.
Fixes#2241.
The `&CasedKeys` system store is a compiler feature that reduces the
repetitive nature of keyboard rules for `CAPS` and `NCAPS`. The
`&CasedKeys` system store defines a list of virtual keys for which
'normal' Caps Lock rules apply. This store has no default value, for
backward compatibility.
Once this store is defined, then you can define just the unshifted and
shifted versions of a rule, and Keyman Developer will synthesize the
`CAPS` and `NCAPS` versions of the rule. For example, you may have the
following rules:
```
store(&CasedKeys) [K_A]
+ [K_A] > 'α'
+ [SHIFT K_A] > 'Α'
```
These would be replaced by the compiler with:
```
store(&CasedKeys) [K_A]
+ [NCAPS K_A] > 'α'
+ [SHIFT CAPS K_A] > 'α'
+ [CAPS K_A] > 'Α'
+ [SHIFT NCAPS K_A] > 'Α'
```
You can also use this functionality with characters in the key part of
the rule:
```
store(&CasedKeys) 'a'..'c'
+ 'a' > 'α'
+ 'A' > 'Α'
```
and the compiled expansion would be similar:
```
store(&CasedKeys) [K_A] [K_B] [K_C]
+ [NCAPS K_A] > 'α'
+ [SHIFT CAPS K_A] > 'α'
+ [CAPS K_A] > 'Α'
+ [SHIFT NCAPS K_A] > 'Α'
```
This feature is backwardly compatible with Keyman 6.0, as it is entirely
implemented in the compiler.
This feature is not compatible with mnemonic layouts, and the keys
defined in the `&CasedKeys` store must be the unshifted base keys as
found on a US English keyboard, or you can use ISO9995 identifiers if
you prefer.
If you define a rule where you specify either `NCAPS` or `CAPS`, for a
key found in the store, then no change will be made to that rule. You
can also continue to define rules which use `NCAPS` or `CAPS` for keys
not found in the store.
As a side-benefit, this allows the visual designer to be used and
support Caps Lock, although at this stage, the `&CasedKeys` store is not
surfaced in the visual designer.
Relates to #2241.
Range expansions are a new language feature that reduce verbosity in
Keyman Keyboard Language (.kmn) files by making it possible to collapse
sequential ranges with a new `..` operator. It is envisioned that these
will be used primarily in stores.
Two kinds of expansions are available: character ranges, and virtual key
ranges.
The syntax is:
```
char '..' char
vkey '..' vkey
```
Where the `char` terminator is a single normal character, and the `vkey`
terminator is a single virtual key. `outs` is permissible for
terminators but no other statement is allowed. Whitespace is per normal
Keyman keyboard language syntax.
Character ranges will replace the range with the set of characters
between the terminators, based on the Unicode value of the terminators.
Examples:
```
store(alphabet) 'a' .. 'z'
store(alpha_not_bq) 'ac'..'pr'..'z'
store(capitals) U+0041 .. U+005A
```
Virtual key ranges work in a similar fashion, but with virtual keys. The
starting and terminating virtual key must have the same shift state.
This will be most useful for character and numeric virtual keys, as the
ranges are based on the numeric value of the virtual key as defined by
Windows, not its position on the keyboard.
Examples:
```
store(alphakeys) [K_A] .. [K_Z]
store(numkeys) [K_0] .. [K_9]
```
Ranges must be positive, that is, you cannot use `'z' .. 'a'`.
While this expansion is not expected to be very useful in rules, it is
still permitted. `context()` and other offsets are calculated on the
expanded form, not the collapsed form. Similarly, `any()`/`index()`
offsets are calculated on the expanded form.
'a' .. 'z' > context(3) c this produces 'c', not 'z'
Because ranges are expanded at compile time, ranges that are overly
long will result in an error, so you cannot use, for example:
```
store(AllUnicode) U+0020 .. U+10FFFF
```
The precise maximum length of a range is dependent on the context where
it is used.
The changes are entirely compiler-based; no change is made to the .kmx
file format or to the Keyman apps.
Fixes#2789.
The Keyboard Fonts dialog skipped some fonts which it did not recognise
as valid TrueType fonts. As a bonus, I've rewritten a few parts of it to
make it significantly faster to load.
I also turned off the font formatting for the list, as it was not very
helpful and hurt performance considerably.
Fixes#4278.
When Keyman Developer is installed without Keyman for Windows, the
program silently crashes, because it is looking for libcef.dll in the
Keyman Desktop install folder rather than using its own copy of it.
This improves the search for libcef.dll and kmbrowserhost.exe, and
includes kmbrowserhost.exe with the Keyman Developer installation.
In the future, we could consider moving kmbrowserhost.exe into a common
folder (perhaps when we split Keyman for Windows and Keyman Developer
projects in 15.0).
I threw in a one-liner addressing a deprecated function warning in the
Developer build.
Fixes#3011.
Keys that have only whitespace will no longer generate separate key data
for the on screen keyboard, as they have no visual presentation anyway.
Fixes#2998.
Three parts to this:
* The package compiler will now give a warning if a keyboard in a
package does not contain any language metadata.
* Removed old canonicalization check during compile which is now handled
better in `TPackageInfoRefreshKeyboards`.
* Reduced non-canonical BCP 47 tag warnings in
`TPackageInfoRefreshKeyboards` to "info" so they do not block the
build.
Point 3 above is one part of the outcome of our BCP 47 discussion at:
https://docs.google.com/document/d/1N5CkTX7tlLlmUB9Mbd-LblY1ch1e642XxlTasC_WE_Q/edit#heading=h.fiy983iliay5
Fixes#3337.
In some situations, the wordlist editor was not tracking modified state
100% correctly, which meant that edits could be lost. This resolves that
by simplifying the modification state tracking.
Fixes#2556.
This adds support for `isRTL`, `insertAfterWord`, and
`quotesForKeepSuggestions` punctuation options for lexical models, both
in the parsing and in the user interface. A number of options are
presented to the user for the quotes and word breaking characters.
The parser continues to be a regex-based typescriptish parser. Expect it
to be gross. It's too big a job to do properly right now, so it is
somewhat limited and will bail if it finds structures it can't
understand.
I would hope to use something a bit smarter in the future to interface
with the editor. Probably when we are actually fully web-based and can
depend on a Typescript compiler directly.
Please don't get mad at me! 😟😟😟
Fixes#2740.
The definitions for several of the combined modifiers was incorrect,
which led to a mismatch when attempting to import those layers from a
visual keyboard into the touch layout editor.
Fixes#4423.
Using a named character constant with a store name that included
characters outside ascii could cause kmcmpdll to crash with an assertion
failure.
This fix allows store names defined in the .kmn file to use characters
outside ascii.
Note that more work needs to be done on which characters are acceptable
to use, as this is somewhat implementation-specific according to the C++
specification for `iswalpha`.
Added a test case to verify various named code constant examples.
Also removes dead code for `IsCJKUnifiedIdeograph` as this was never
used and somewhat pointless in any case.
NamedCodeConstants.cpp could stand to be rewritten using `std::map` or
equivalent. Current implementation is pretty icky.
Fixes#4221.
When the Keyman Developer IDE calls out to the lexical model compiler,
it receives UTF-8 compiler message strings back but they are treated as
Windows-1252 strings. This fixes that.
