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.
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.
We no longer need to backup debug files as they are saved to the symbol
store during a release build. This reduces the amount of storage
required for a release build and should speed up the build also.
Also fixes the broken build where backup had not been updated for the
new consistent build paths.
Move to all projects using bin/ and obj/ for outputs, and
cleanup all Makefiles and project files accordingly. Remove
some obsolete projects along the way. Cleanup .gitignore
also.
Fixes#5245.
Interfaces should remain stable between versions of Keyman, so that an
upgraded kmcomapi.dll or keyman32.dll will not crash older clients, even
if they may not behave entirely as expected.
Fixes#519.
I have removed these .cfg, .dof, and .bdsproj files from the primary
projects in the Windows source. There is some ambiguity as to whether
.cfg files are used by the command line compiler (I checked with procmon
and they *are* read by dcc32.exe), so we will need to make sure that
no adverse changes have been made by this. In theory at least, the
.dproj data trumps .cfg data -- and all the projects in question have
a .dproj file -- so this should be a safe cleanup.
I have opted not to touch the /buildutils, /ext, /support and
/test folders at this point.
Fixes#5004.
This cleans up the use of controller windows. A single window is now
given the responsibility of being the master controller, which receives
messages from Keyman32 and other components around UI activation, active
keyboard, etc.
The master controller is keyman.exe's `TApplication` window, which does
not get destroyed and recreated, unlike the main form window.
Any thread which has responsibility for Keyman UI (keyman.exe main
thread, keymanx64.exe main thread) is also registered as a controller
thread. A controller thread has special handling for interactions with
keyman32 around focus tracking.
Caveats:
* While keymanx64 does not have a visible window and thus probably does
not need to be registered as a controller thread, it doesn't really
hurt.
* Note that keymanx64 registers the 32-bit controller thread as well,
which again is probably unnecessary as the 64-bit process cannot
interact with the 32-bit thread.
* Keyman's main form still handles wm_keyman_control messages, as there
are a number of other components which post to that window (e.g. text
editor, com library visual keyboard interactions). Unlike the original
problem trigger, the reference handle is not stored long-term and so
there is unlikely to be a problem with main form window re-creation
causing an issue in these contexts.
There are several TODO items in this which I will address in follow-ups,
to reduce the scope of these changes.
I hope to cherry-pick this to stable-14.0, but will run for a while in
15.0 before doing so.
Fixes#4939.
Fixes KEYMAN-WINDOWS-70.
Fixes KEYMAN-WINDOWS-71.
Fixes KEYMAN-WINDOWS-BR.
Fixes KEYMAN-WINDOWS-6J.
I am speculating a little here, because the root cause is not visible in
the crash report, but it appears that if keyman32.dll is renamed, that
the UnregisterControllerWindows function attempts to reload keyman32.dll
which means that (a) it no longer has a list of registered controllers,
and (b) it may fail to reload.
Instead of throwing an exception, we now only log this error in
development mode. The error is not likely to cause significant trouble
for end users as they are shutting down Keyman anyway at this point.
The resolution if there is any uncertainty during an upgrade is to
restart Windows. This is less than ideal but avoids file locks and
problems with in-memory DLLs. (Future versions of Keyman will schedule
upgrades to happen automatically after a restart before Keyman has been
started, in an effort to avoid this kind of trauma.)
Fixes#4447.
Fixes#4222.
The symptoms for these two issues are related: the language associations
change and keyboards stop functioning correctly. The issue is described
in detail in #4447.
Although this fix should be considered 'experimental', we should
probably include it in the release of 14.0, because it fixes a
longstanding issue with Keyman and Windows languages.
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.
We should uninstall transient languages before disabling them
because once we have disabled them, we lose the language
association and cannot find the entry to uninstall. catch-22.
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#4343.
This patch makes all language codes from the langtags.json dataset
visible through the Add Language dialog. This avoids situations where
an incomplete code such as "cmo" can result in an error (a script is
required for "cmo" as it is written in either Latn or Khmr).
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#4264.
The Android strings.xml format that we now use with Keyman Desktop has a
number of escapes that must be supported in order for text strings to be
rendered correctly, including: @, ?, ', ". Furthermore, positional
parameters have a slightly different format which we should transform on
load.
This change includes a unit test androidstringtokeymanlocalestring.
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.
This change has three fixes to improve the reliability of notifying
Keyman Engine of updates to settings or keyboard installs:
1. It removes the closure pattern of the refresh thread, because that
was closing on a variable on a different thread (`RefreshHandle`) and
that could cause races and/or exceptions in the case of early free.
What's more, the closure was actually unnecessary as the variable was
really only used by the refresh thread!
2. It moves responsibility for setting the refresh token to the calling
thread so that the caller can depend on the token being the one that
is actually sent, removing a race.
3. Most important, the refresh thread now flushes all messages in its
queue, as there may be multiple messages relating to the window
construction that need to be processed before the wm_keyman_refresh
message can be handled. This greatly improves the chance of the
notification actually being sent!
Fixes#4006.
This fixes the list error exception which was masking the actual cause
of #4006, which is already fixed by #4164.
Related issue #4119 is also fixed by #4164.
Fixes#4011.
Fixes#4039.
Fixes#4121.
This change completes the immediate-change model for Keyman
Configuration, by refactoring the refresh of settings out of the render
phase and more appropriately splitting applying and refreshing. It adds
a new message flag for wm_keyman_refresh, KR_SETTINGS_CHANGED, which
uses a random token approach broadcast to all applications on the
desktop to ensure that the refresh is received and multiple
notifications for the same event can be appropriately coalesced.
Most of the files touched are stripping out the refresh flags from the
render phase.
There is one small bug resolved at the same time with the options
properties, which were not reset to default if they had been deleted
from the registry prior to a refresh (see utilkeymanoption.pas).
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#4003.
This addresses the majority of locations where we use the name "Keyman
Desktop" in code. There will be some filenames and paths that do not
change at this point -- particularly at a source level. For now, the
focus is on the user interface changes.
While making these changes, I also made the VERSION and MANIFEST
resources more consistent.
Fixes#3831.
This fixes both issues reported in the bug (dproj changes ensure
separate .tds, and Makefile changes fix order of execution so that
dbg is generated after sentryprep's cleanup).
Relates to #799.
Removes NRSIAllTags, alltags.txt, parser and utility units.
Also re-enables standardsdata.dpr unit test which needed some syntax
cleanup.
Fixes#3801.
Fixes#3802.
Fixes KEYMAN-WINDOWS-5M.
Fixes KEYMAN-WINDOWS-5N.
This is a two-part fix for Keyman Configuration where it appears there
was a race with creating a temporary file, and which caused a cascading
exception.
The first part resolves the race; the second part (in
UfrmInstallKeyboard.pas) adds a little extra robustness (probably not
totally necessary).
Fixes#3518.
Changes in Keyman Configuration will now apply immediately. This removes
the OK and Cancel buttons from the dialog and means that all actions
are consistent in when they are applied, unlike previously. This also
matches the Windows 10 Settings metaphor and metaphors for most modern
apps and devices.
For now, I have placed a message where the OK and Buttons were
previously, to help existing users understand the change. In time, I
expect us to be able to remove that message entirely.
Release build executables should have 3 component version numbers with
the version tag appended, e.g. keymandesktop-14.0.155-alpha-local.exe.
Coming later, rename keymandesktop-version.exe to keyman-version.exe.
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.
