Feature request - offer to quit and relaunch apps when updating
ofirgalcon opened this issue · comments
Managed Software Centre (like the Apple AppStore) should ideally offer users the option to quit, update and relaunch apps automatically.
This is an old request of mine that was discussed in the past, but I never posted it here.
It's not something I'm likely to work on in the near future. If someone else would like to tackle it, I'd be happy to review any work.
Just a note here in case someone decides to attempt to implement this. The App Store has an easier task here because App Store Apps, in order to be accepted, must meet specific requirements. I think one of these is that the app must be able to be quit without prompting the user to save changed documents, stop additional processes, etc. To generically support this in MSC, which can install all sorts of software that doesn't adhere to the App Store guidelines, you'd have to account for apps that don't quit immediately, but instead prompt the user to do something first (and there's no guarantee the user will actually do the thing). How long should MSC wait? What should it do if some of the apps don't quit? IOW, there's some user interaction/user experience that needs to be thought about and designed.
I tried to verify the behaviour. So far
- If an app is closed it just updates it
- If an app is open it prompts you to close it but does it directly from the appstore
Jamf it seems just force quits
What if MSC kept the current behavior as the default and introduced a new key, e.g. relaunch: bool. If True, then MSC would quit and relaunch the app if it's running. That gives admins that ability to test which software works out of the box and apply the "relaunch" key to only those.
My thoughts on quitting the applications are to use (I think it's) signal 3, QUIT. I don't think applications should be quit in a way that could lose a user's work. That said, an alternative approach could be another key, e.g. quit_method: str, that let's the admin set the QUIT or KILL signal which might be needed in a compliance scenario – or maybe this could be paired with the force_install_after_date to escalate from QUIT to KILL.
See #1157 (comment)
@bryanheinz The more complexity here, the more to maintain and the more to test. I'd advocate for only using NSApplication's terminate method: https://developer.apple.com/documentation/appkit/nsapplication/1428417-terminate?language=objc
You'd probably use NSWorkspace.sharedWorkspace to get a list of open apps, then iterate though each one and call app.terminate().
But some difficulties: how long do you wait after sending the terminate message? What do you do if the user realizes they have an unsaved document and then decides, no, not is a good time to save and quit? There's many scenarios/"user stories" that you'll need to account for/handle.
Another one: what do you do/what would the user expect, if only some apps were successfully terminated? Should Munki try to install the things it can? How is that communicated to the user?
My preference, regardless of this feature idea, is that Managed Software Centre should always install what it can. Sometimes users need to install something and do not want to quit Chrome or whatever app they are using to allow update. It means they end up not using Managed Software Centre and going to google instead to search for the download.
I think that's a good goal and reasonable thing to want. Munki will of course install what it can during a background run. The challenge in MSC.app is more of UI/UX: how do you communicate to the user "Here are six updates. Three are blocked by open apps. Install the other three?". None of this is technically difficult, but it's design work and user testing work that must be done. Who is offering to do it?
For the record, I am interested in building it, but I can't commit to it anytime soon. That's why I'm giving my 2¢ and am interested in fleshing out the concept.