feat(windows): kmshell switch handling for the installing state #12956
Conversation
Also handle the case where the SM seems to be stuck in the installing state. MSI may have failed.
keymanapp-test-bot
bot
added
the
user-test-missing
User Test ResultsTest specification and instructions ERROR: user tests have not yet been defined Test Artifacts |
rc-swag
changed the base branch from
master
to
feat/windows/test-online-update
| UserCanceled := False; | ||
| if BUpdateSM.ReadyToInstall and | ||
| (not FSilent and (FMode in [fmStart, fmSplash, fmMain, fmAbout, fmHelp, | ||
| fmShowHelp, fmSettings])) then |
There was a problem hiding this comment.
@marc I have added fmShowHelp, and fmSettings as gui's where we could notify the user we can pop keyman update is ready to install. select update, or close.
However, I am still not happy that we are missing the all-important case when Keyman starts with Windows which is simply kmshell.exe -s I propose we update this to have a switch -on-boot so kmshell.exe -s -on-boot then we could determine this is a case where the UI can be run. Thoughts?
There was a problem hiding this comment.
kmshell -s means 'silent' so that means no UI is intended to be shown there... We could change that to kmshell.exe -boot, but we'd have to fixup existing installations -- we'd need to make sure that that change was applied during the upgrade (this is quite doable, just more work and testing).
I think that'd be good because it'd be clearer than the current -s which could be used any time and is ambiguous.
This improves the switch handling around the installing state. Previously, the SM did a no-op and let the commands go through. This now only sends the commands through to the SM when installing that it should receive. This then allows us to detect when we are in incorrect state of have Keyman installation but the state machine is still in the installing state.