If the app termination request is delayed or canceled, the user can check for updates again with the standard user driver and try installing/relaunching again, which will trigger the installer to send another quit event to the running application.
Before the install/relaunch window would close but the check for updates option would still be present but not functional.
* Use UniformTypeIdentifiers framework to replace deprecated types
kUTType* constants are deprecated since macOS 12. The UniformTypeIdentifiers framework is available since the macOS 11 SDK.
* Replace renamed constants
* Use API_AVAILABLE macro instead of __OSX_AVAILABLE
We unify the user driver method showing the update to take a generic state object now. The current fields of the state object are its current stage, if it's user initiated, and if the update is a major one.
We also remove deprecated code paths that were complex to support and will otherwise generate in compile errors if people adopt the new API.
We don't have a dismiss method for every transition state and we don't want to. This should be up to the UI to determine how to transition from one UI state to another UI state.
When the update is shown to the user, the menu item for checking for updates is no longer disabled. Instead it is enabled, and when invoked, will bring the update to utmost focus back to the user again.
This is consistent with other options (eg Preferences...) that bring up windows. Improved user experience here is that updates are now less "lost".
We (re)define properties on SPUUpdater:
canCheckForUpdates - to mean that the user can check for updates (start a new update check or show the already present update frontmost)
sessionInProgress - to mean if Sparkle's internal driver / scheduler is running (i.e, downloading appcast or update, showing update, starting installation).
This reduces friction in creating a SPUUserDriver. This assumption that the calls could be made from any thread is a relic of the past of separating the user driver into a different process from the updater/scheduler, which is no longer sane or supported.
This should speed up things very slightly too.
This will increase the chance of a user driver implementing being able to show informational only updates. Also it's better to use a new method rather than re-use another existing one inappropriately.
This is better than the hack in the previous commit. Also, a user driver may very well want to act differently in showing UI if the user initiated the update check.
This allows us to remove SPUUserDriverUIComponent and remove a bunch of logic in the user driver regarding termination. The user drivers generally don't need to know about the application bundle anymore, and strictly now only show UI events.
This has another advantage of the agent being able to quit multiple instances of an application even if the application to update is sandboxed.
We enforce the logic that an application can only be relaunched if it was running initially.
This is triggered if the update is automatically downloaded and the installer is started in the background, and the updater's delegate decides to handle silent installation and installs the update invoking its immediate installation block. In this scenario, this fixes an issue where the application may not be terminated silently.
Although it is interesting to separate the user driver and update scheduler in different processes, this has yet to prove useful. Further, this management should not exist in the user driver protocol since the protocol would be doing double duty. If this separation is useful in the future, it should be separated into another driver altogether. Note that it is also hard to write correct code that separates the user driver and updater. Removing this code should greatly reduce maintenance costs.
This fixes issues where the user driver may not be displaying release notes properly because it doesn't know what kind of data was downloaded (eg: html vs plain text).
Zorg
Eitot