Fixes#4192.
If Keyman is already running, and the user attempts to start Keyman
again, a balloon will be shown to direct the user to the right place on
the screen.
Note: this worked in earlier versions of Keyman but stopped working due
to name changes for windows in the app.
I have also added a new string for balloon that will need translation.
Fixes#4013.
This turned out to be a lot more complicated than I expected, mostly due
to limitations in the Windows Shell API with regard to multiple monitors
and per-monitor DPI awareness (which we don't yet do in Keyman -- a
task for another day). Some of the Shell API functions are also
re-entrant, which is dangerous, so I avoided using those.
We now popup the menu relative to the Keyman icon far more precisely
which gives a much nicer feel to the menu interaction.
Another thought: we could also try refreshing every 125msec for 5
seconds after the first change is detected. It's a bit yuck perf-wise
but would probably be pretty transparent to the user.
In testing, this looks good. It means the changes appear as soon as
ready, without substantial delays or performance issues. Polling this
makes me feel a bit dirty, but I'll just take a shower and be okay.
As Keyman now monitors the Windows keyboard list from Control Panel, it
is no longer sufficient to refresh the toolbar only when a Keyman
keyboard is updated, as at that point Windows has not refreshed its own
language list in the registry. Instead, we need to monitor changes to
the relevant registry key and then refresh when those changes are
'complete'.
There is a problem: there does not appear to be a good way to monitor
for changes to Windows language settings. WM_SETTINGCHANGE is sent when
a language is added by the user in Settings, but the actual change
happens asynchronously, and we are not notified when the changes are
complete.
We also do not get notifications when languages are added via APIs.
Given the async nature of the language profile changes, this leads to
race conditions when we try to refresh the OSK toolbar. My preferred
solution currently is to monitor the relevant key in a separate thread,
and wait 1 second post-changes to actually do the refresh.
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#1843.
If there are so many keyboards installed that the menu would grow larger
than 3/4 of the screen height, then the menu will become scrollable.
Fixes#2450. When Keyman serialized input, it would cause the touch keyboard to cancel
because the touch keyboard thought the received event meant the user was touching the
physical keyboard. This resolves that problem, using a watch timer to check the visibility
of the touch input panel.
Just refactoring minor bits and pieces on this PR. Esp: removed the
unnecessary interrogation of TSF (yay!) and cached the debug flag so it
isn't checked on every single keystroke.
Fixes#364.
Hotkeys in Windows are currently implemented using RegisterHotkey.
However RegisterHotkey does not distinguish between left and right
modifier keys, which means that they override some keyboards' RAlt
combinations.
This feature reimplements hotkey support in the low level keyboard hook,
and adds a feature flag / debug flag Flag_UseRegisterHotkey to return
to the RegisterHotkey model if that is so needed.
I have made minimal refactoring changes to this code, although there
are certainly functions here which could be improved.
I have flagged a couple of potential improvements with TODO.
Fixes#2147.
This potentially addresses the issues reported in #2147 where Keyman
would crash due to a race condition as a critical section was not
deleted before attempting to recreate it.
Some logging has been added for debugging these issues.
Also fixes memory leaks and another race on startup relating to loading
the taskbar icon.
There are still some known memory leaks because DLL_THREAD_DETACH is
not called for all threads before keyman32.dll is unloaded, so those
threads don't get the opportunity to clean themsselves up. However, the
key danger with the csGlobals critical section has been addressed.
