Install.app launches in semi-background from PrefsPanel

[Peter Speck]

When Sparkle launches Installer.app from within a System Preferences Panel, the Installer window comes between the system preferences window and Sparkle's dialog window. See attachment.

Launching Installer.app using the "open" command avoids this.

Patch attached. For 10.4 and earlier it falls back to the old method as the 'open' command in 10.4 doesn't support the required options.

[Andy Matuschak (andymatuschak)]

Thanks for the patch, Peter! Fixed in r317--please verify the change.

[Peter Speck (speck)]

I think the committed version will fail on 10.4 as the open command in 10.4 doesn't support the required options (at least from the 'man' page, I don't have GUI access to a 10.4 system).

So I would propose keeping the "floor(NSAppKitVersionNumber) > NSAppKitVersionNumber10_4" test and the fallback for 10.4 to run the installer using absolutePathForAppBundleWithIdentifier.

[Andy Matuschak (andymatuschak)]

Oh ho! I totally misread that inequality. Okay, fixed in 318.

[Peter Speck (speck)]

Negative. It's not in 318 (aka the trunk). 318 has Turner's 271378: Sparkle is now willing to install a bundle in the archive with the same bundle identifier as the running app as a fallback strategy. .

[Andy Matuschak (andymatuschak)]

waitwaitwait, really? What's line 20 of SUPackageInstaller.m say when you check it out?

[Peter Speck (speck)]

From clean "bzr branch lp:sparkle":

@implementation SUPackageInstaller

+ (void)performInstallationWithPath:(NSString *)path host:(SUHost *)host delegate:delegate synchronously:(BOOL)synchronously versionComparator:(id <SUVersionComparison>)comparator;
{
    NSError *error = nil;
    BOOL result = YES;

    NSString* openCommand = @"/usr/bin/open";
    if ([[NSFileManager defaultManager] fileExistsAtPath:openCommand])
    {
        // Using "open" insures that the installer application is brought to the front.
        // The -W and -n options were added to the 'open' command in 10.5
        // -W = wait until the app has quit. -n = Open another instance if already open.
        // -b = app bundle identifier
        NSArray *args = [NSArray arrayWithObjects:@"-W", @"-n", @"-b", @"com.apple.installer", path, nil];
        NSTask *openTask = [NSTask launchedTaskWithLaunchPath:openCommand arguments:args];
        [openTask waitUntilExit];
    }
    else
    {
        error = [NSError errorWithDomain:SUSparkleErrorDomain code:SUMissingInstallerToolError userInfo:[NSDictionary dictionaryWithObject:@"Couldn't find Apple's installer tool!" forKey:NSLocalizedDescriptionKey]];
        result = NO;
    }

    // Known bug: if the installation fails or is canceled, Sparkle goes ahead and restarts, thinking everything is fine.
    [self _finishInstallationWithResult:result host:host error:error delegate:delegate];
}

@end

[Peter Speck (speck)]

I've submitted a branch which falls back to Installer.app on 10.4

(seems like I lost a previous comment/email)

The Sparkle test app downloads an app package and not an installer, so I couldn't test the current code, nor the proposed patch.

However, running the following command on 10.4
   open -W -n -b com.apple.TextEdit ~/Library/Preferences/Preview.plist
fails with:
  2009-01-06 23:00:57.971 open[5855] No such file: /Users/ks/-W

So the 'open' command can be ruled out for 10.4 when the execution flow has to be blocked while installing.