markcarver/Sparkle — comment on commit 3f1d59343168237e760951cb6026b26b8a6f9b34
File:  line 0
By markcarver:

>Hm. I’m not sure the semantics are that weird. I can imagine an app not wanting to be relaunched due to some long-running, non-abortable operation. The delegate’s really preventing the relaunch there, not the actual installation of the update.

Exactly how this _used_ to work. However, the current `updaterShouldRelaunchApplication:` method is invoking `mayUpdateAndRestart` before the rest of the method has a chance to run. As it stands now, if the delegate subclasses `updaterShouldRelaunchApplication:` and returns `NO` then `abortUpdate` is called and the new `finish_installation` tool does not get ran, thus not installing the actual update (which _is_ delegated to the new `finish_installation` tool).

In `SUUpdater.m`:

- (BOOL)mayUpdateAndRestart {
return( !delegate || ![delegate respondsToSelector: @selector(updaterShouldRelaunchApplication:)] || [delegate updaterShouldRelaunchApplication: self] );
}

In `SUBasicUpdateDriver.m`:

- (void)installWithToolAndRelaunch:(BOOL)relaunch {
if (![updater mayUpdateAndRestart]) {
[self abortUpdate];
return;
}
<<>>
}

Essentially, I think the selector names and even some properties should probably be renamed to reflect the new `finish_installation` tool. `(BOOL) relaunch` is simply an argument that is passed to the tool now.

Granted, in hind-sight, I don't think the method `updaterShouldInstallApplication:` is actually really necessary. We just need to move the method `updaterShouldRelaunchApplication:` further down in the `installWithToolAndRelaunch:` method and not invoke `mayUpdateAndRestart`.

>But that would lead to the app being terminated without any user input!

Indeed, but I was under the impression that that is what this branch was for (quiet-automatic-update), to provide a fully automatic update and install with-out the prompts? Granted, most applications would not have the need for this per-say, so they shouldn't subclass this delegate method. But in my case:

`cocoaDialog update` will run the update run-mode, complete with dialogs. However because it's a third-party support application (to be used in other scripts) often the user is unaware that `cocoaDialog` even exists. So the script could call something like `cocoaDialog update --quiet`, which in turn translates into cocoaDialog utilizing this delegate method to suppress any dialogs from Sparkle and simply update it to the latest version. The script then can continue with the current version (if no update existed) or have comfort knowing that they have the latest version all the time.