While .kvk includes a font color field, it is essentially unused. There
was also some sort of support provided for font style in the KeymanWeb
keyboard compiler, but this was never streamed into .kvk or .kvks files,
so was always a no-op.
Thus, this PR removes any semblance of support for font style and color
from the .kvk and .kvks readers and writers. When we write the font
color field which is present in .kvk, we always use the default
TColor.clWindowText which is what the legacy Delphi-based writer would
always have written.
Also sorted out the default font size and name in the .kvk transform
from .kvks, and in so doing cleaned up the basic.kvk and basic.js in
LDML keyboard compiler to match what we are doing in the .kmn compiler.
Fixes#5091.
If the user has a default language that is not a minimal BCP47 tag, such
as `zh-Hans-CN` vs `zh-CN`, or if the default language does not have a
mapping in our `TLanguageCodeUtils.TranslateWindowsLanguagesToBCP47`
function, then kmshell would crash on install of a keyboard that had no
language metadata specified (i.e. neither legacy metadata in .kmx nor
modern metadata in .kmp).
This crash arose because the elevated instance of kmshell would install
a local-machine reference to `zh-CN` (as it back-translated from a
LangID), but the current user install would look for `zh-Hans-CN`, read
from the Windows registry `HKCU\Control Panel\International\User Profile`.
To further complicate matters, it is possible for the current user to
have a different default language than the elevated user on the machine.
Keyman was assuming that the default language was the same in both
cases.
This fix passes in the current user's default BCP47 and LangID to the
elevated portion of the keyboard install, so we can guarantee that
keyboard install which needs to use the default language, actually
installs for the current user's actual language code, and not a
canonicalized version (or a totally different code in the case of
elevation to an alternate admin user account).
Fixes#5683.
If `store(&name)` is missing from a keyboard, then fallback to the
filename of the keyboard (sans extension). This fixes a regression in
14.0 keyboard registration.
I opted not to make this change in kmxfile but rather in places which
use it in the Keyman Engine COM API, because I wanted kmxfile to remain
truthful about all details of what it is reading from the file.
Given that the COM API will now never return an empty string for the
name of the keyboard, there are mitigations for this in Keyman
Configuration which are unnecessary, but it is not harmful for them to
remain there.
Will cherry-pick to stable-14.0.
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.
Ensures we get a canonical tag per langtags.json as far as we possibly
can. This is a breaking change for the compiler as tags which were
formerly regarded as canonical are no longer regarded that way. This
mostly relates to script subtag but a secondary bug meant that some
other tags would have lost data in the canonicalization process
(because we did a lookup based only on the language subtag previously,
which is a no-no).
See keymanapp/keyboards#1452 for related work.
Fixes#4337.
The Sinhala language installation mitigation needed the BCP 47 code as
well as the language code with the new language installation process.
Fixes#4184.
If a package had a keyboard with language metadata, it would not
load that language data correctly, which then meant it would not
apply the mitigation correctly either, leading to a double elevation
dialog as Keyman tried to fallback to primary language.
Fixes#1285.
If running Windows 10 19597 or later, the underlying issue has
been addressed, so disable the mitigation for new installs of
the keyboard. Does not attempt to change the language code if
the keyboard is already installed.
The keyboard profile and registration strategy was not taking into
account the mitigation for Win10 1803 (#1285) and this meant that the
Amharic, Tigrigna and Sinhala keyboards would not install correctly.
Fixes#3749.
Fixes#3759.
Adds a warning dialog when user attempts to add a transient language to
a keyboard but the maximum number of transient languages is already
installed.
If this issue arises when a user is installing a keyboard for the first
time, Keyman instead installs the keyboard for the user's default
language. This may be a little confusing, but the error condition is
difficult to explain and non-technical users will probably be stuck
and need to install under their default language in any case. Happy to
receive any pushback on this decision.
Fixes#3561.
Resolves issues with upgrading disabled keyboards, and fixes a secondary
issue where Windows was giving us invalid LANGIDs for locales, which was
causing trouble with transient LANGIDs.
Relates to #3561.
If a keyboard is installed for a transitional profile but another
keyboard is already installed for that profile, then Keyman would
crash, expecting the transitional profile to be missing.
Fixes#3560. This reworks the functionality for disabling
keyboards to work with the new TIP registration pattern. Much
of the code is the same as in Keyman 13, but there are some
significant differences, so it all needs to be reviewed.
This upgrades a 11.0-13.0 install to the 14.0 model for registered TIPs.
It does not yet deal with transient TIPs or disabled keyboards (these
will come in a separate PR). There is also more tidy up coming in a
future PR for language names.
This PR handles the case where Windows installs a BCP 47 tag that may not
match our tag 100% precisely. In this case, Keyman maps the Windows BCP 47
tag to the in-memory data for consistency. It also allows for install of
more complex tags.
