This starts the refactoring of Keyman Setup for Windows
for a more online-first bootstrap approach for bundling.
For users who are offline, the traditional bundled approach
works, as does throwing package files into the same folder
as setup.exe. This makes the whole installer much simpler
to deploy and test.
At this stage, there are a lot of rough edges, so need to
refine these, including setup strings, language choices,
and error and logging management.
This updates Sentry integration to use the exception object which
gives better tracking and consolidation over time, once we learned
how to report the call stack more reliably.
Works around #119 on the compiler side. This normalises the touch layout file in the
compile phase, fixing integers which should be strings, etc. This means that
we no longer need to correct the issue in the Engine; a rebuild of affected
keyboards is sufficient (although of course we'll need a version bump in order
for them to be distributed.
Start moving data from forms to models/controllers for
onlineupdate and establish a shared data pattern for
transitional refactoring. Also establish a TLocaleStrings
class which has no global variable dependency.
Serve all Keyman Configuration dialogs over a local http server
instead of over file protocol. This is more secure and allows for
a bunch of things in the future, including simple online integration
and stable reporting.
kmshell had no application.title set and this gave incorrect
results for crash report dialog.
kmbrowserhost was acting as a VCL app but it isn't, and the
sentry integration was pulling in all the VCL dependencies which
was a bad outcome. This removes those and handles crashes as a
non-VCL app.
When Sentry is trying to shutdown an app which has CEF windows active,
the main process can hang waiting for the CEF renderer etc processes to
shutdown. Instead, we now rely on the child (CEF renderer etc) processes
to shutdown when their parent process aborts, with a watchdog thread, and
then abandon everything in the parent process with ExitProcess. This is
more reliable, especially with nastier crashes like memory corruption or
stack corruption.
