A few fixes and improvements:
* kmconvert was missing a command line parameter for `-target` to
specify the platform targets for a project
* kmconvert should avoid throwing unhandled exceptions, rather if
sentry is not present then just write to console.
* Include kmconvert and its data files in the deployment of kmcomp.zip,
which is done on the build agent (just need to make sure files are
in the right place here.)
* Side fix: also made sure kmcomp would emit the exception message to
console if sentry is not present.
It turns out that the Debian package build system only considers
the first alternative; python3-raven isn't available on the current
Debian version, however we still need it on Ubuntu 18.04 Bionic where
python3-sentry-sdk is not available. This change swaps the
alternatives and so should work both on Debian as well as for
Bionic.
The `KMC_CHANGEUISTATE` flag for `wm_keyman_control` is no longer
processed anywhere. Removes it and the `UpdateKeymanUI` function which
called it.
The `#define` for the flag has been left, commented out, to clarify what
would otherwise be a gap in identifiers (use `git blame` to learn more).
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.
UFixupMissingFile referred to an old MSI component code, which meant
that it would never actually fix the installation. This now refers to a
current component code.
I may backport this to stable-14.0 but would like to assess its
stability over time first.
