If the list of actions that Setup will perform is too long, a scrollbar
will now be shown. This will probably not arise frequently but certainly
helps if it does.
Fixes#3689.
When Setup is starting, it can sometimes take a few seconds to show the
main form because it is querying an online server and unzipping various
files. This shows a small progress bar window so that the user doesn't
wonder what is going on.
The progress bar is fairly basic: it has only 4 steps, and because all
actions are happening on the main thread, does not animate well or
smoothly. In my view, it is not worth redesigning into a multi-threaded
process for the sake of this progress bar dialog.
Relates to #3689.
Where more than one source of a file is available, e.g. a local
keymandesktop.msi which is older than the current published version
online, then Setup will choose the newer, online version by default,
but allows the user to change the install source in the Options dialog
to have an offline setup if they prefer.
This means that the 'best' location is now chosen at startup, and then
the user can override that.
Relates to #3689.
There were a number of obsolete values in setup.inf, and removing those
led to a small cascade of changes:
1. `MSIOptions` and `Version` properties were removed.
2. `Version` is now read directly from the .msi if it is present.
3. Package name and version are now read directly from local .kmp files,
rather than relying on metadata in setup.inf.
4. Setup now only loads .kmp files that are referenced in setup.inf, to
avoid scenarios where a user downloads the installer into a common
location that already includes .kmp files and is then confused by
why it is offering to install those files as well.
5. `Strings` property is not used outside of `TInstallInfo`.
Fixes#3650.
This removes the bad call to `FreeLibrary` that was still present in
a callee of `DllMain` in keyman32. The refactor moves responsibility for
loading TSF to the `SelectKeyboard` functions and gets rid of the
associated thread globals.
The `TSFINTERFACES` struct is of course a future candidate for a class.
In the process I removed a lot of cruft from keyman32.cpp which was
either obsolete, irrelevant or just plain wrong. None of which had
material impact on the running code.
1. Remove unused variables
2. Remove invalid build configurations
3. Move hotkey checks before touch keyboard panel check, so hotkeys
still work when touch panel is active; the touch keyboard panel check
is there to disable serialised input which conflicts with it.
Fixes#3562.
Second part of the two-part special with #3772. When Keyman
Configuration starts, it creates a task that is launched whenever a
specific Keyman event with id 256 is added to the Event Log. This task
launches keyman.exe to start Keyman (and if Keyman is already running,
the newly launched process will exit with no side effects).
This feature is behind a new feature flag `Flag_UseAutoStartTask`, so it
can be disabled in the event of compatibility issues.
The task is created or updated on each launch of Keyman Configuration
(or Keyman via the 'Keyman' shortcut in the Start Menu), and is
intended to be self-maintaining.
The test_starttask project (4 of the 12 files) is just a wrapper around
the start TKeymanStartTask class to allow for manual testing. No unit
tests for this at this time; I think it would be difficult to unit test
this effectively.
This is the first half of a two-part update to Keyman for Windows. There
are two significant changes here. These changes apply to
keyman32/keyman64, as well as kmtip/kmtip64, but will refer to the
32-bit equivalents for simplicity:
1. Instead of using `GetProcAddress` to connect to keyman32.dll, we
now have an import library connection. This removes one particularly
suspect piece of architecture for Keyman, as using `GetProcAddress`
could lead to a race condition, where keyman32.dll is unloaded after
that function is called but before we use the handle. This makes the
kmtip.dll build dependent on keyman32.dll; loading kmtip.dll (by
selecting a Keyman input method) also loads keyman32.dll.
2. It's not enough (yet) to load kmtip.dll. We also need to be running
keyman.exe itself, due to global hooks that we still require (it may
be possible, one day, to avoid these, but it doesn't look very
hopeful). To that end, kmtip calls new function `TIPIsKeymanRunning`
to check whether keyman32.dll is initialised (and hence keyman.exe
has initialised it). Then, if keyman.exe is not running, it issues an
event to the Windows Event Log, which we will pick up with a
scheduled task in the next PR.
The first part of this is an architectural change which may lead to some
change in behaviours, as keyman32.dll now may not be unloaded from a
process when keyman.exe exits, due to the lock that kmtip.dll now has on
it. It will be important to test this (@MakaraSok) by running through
various startup and shutdown scenarios. In my initial testing, I found
that there were some situations after restarting keyman.exe where I
needed to switch in and out of the Keyman TIP, but those were not all
critical.
This change also lays groundwork for an eventual ability to run the
Keyman input method without keyman.exe running, which will be helpful
e.g. on login screen, even if missing certain additional functionality
such as the serialised input queue.
As some of config state was cached, it would not refresh correctly
when displaying. This ensures that the config renderer uses its
own new instance of the COM API data on every refresh.
Both the win32 and the win64 keyman engine libraries would receive a
refresh notification, and then they'd both broadcast the change. This
change limits the broadcast responsibility to the 32-bit engine.
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.
