the 'criticalUpdate' feature is just remove the skip and remind me later buttons?

[gaojinhsu]

Summary

What I want is a real force update, which means when I launch an old version app, the update alert view should show up as soon as possible, besides, the alert view is disabled to be dismissed unless the install button is clicked to do the next step.

Version

1.26.0

[zorgiepoo]

Critical updates also get higher precedence to showing an update alert more immediately (especially if updates are set to automatically download/install).

I think this was sort of discussed in #138. This is a feature request. I am not sure if this is a good idea, the update alert window is also not modal.

Flushing out and fixing appcast selection on existing features is more of my priority right now rather than adding additional features. For example a critical update cannot presently only apply updating from less than a specific version.

[zorgiepoo]

Thinking about this more, in my opinion having an update alert that cannot be skipped and shows up each time the scheduler kicks in is obstructive enough to forcing the user to update. One can disable closing the window (which is equivalent to remind me later) to be a little more obstructive, perhaps, but that may irritate the user.. I don't really want the window to be modal (preventing other parts of the app from being used).

[gaojinhsu]

Thinking about this more, in my opinion having an update alert that cannot be skipped and shows up each time the scheduler kicks in is obstructive enough to forcing the user to update. One can disable closing the window (which is equivalent to remind me later) to be a little more obstructive, perhaps, but that may irritate the user.. I don't really want the window to be modal (preventing other parts of the app from being used).

In some reason, I have to implement the "force" or "required" update, So I decide to implement it by myself, I change the SUUpdateAlert to modal, and it works, but when it comes to SUStatusController, the download session seems to be blocked. here is my code in 'SUUIBaseUpdateDriver.m'

 - (void)downloadUpdate
{
    BOOL createdStatusController = NO;
    if (self.statusController == nil) {
        self.statusController = [[SUStatusController alloc] initWithHost:self.host];
        createdStatusController = YES;
    }
    
    [self.statusController beginActionWithTitle:SULocalizedString(@"Downloading update...", @"Take care not to overflow the status window.") maxProgressValue:0.0 statusText:nil];
    [self.statusController setButtonTitle:SULocalizedString(@"Cancel", nil) target:self action:@selector(cancelDownload:) isDefault:NO];
    [self.statusController setButtonEnabled:YES];
    
    if (createdStatusController) {
        if (self.updateItem.isRequiredUpdate) {
            NSWindow *window = self.statusController.window;
            [[NSApplication sharedApplication]runModalForWindow: window];
        } else {
            [self.statusController showWindow:self];
        }
    }
    
    [super downloadUpdate];
}

any advice?

[zorgiepoo]

1. If it meets your needs, just enable automatic downloading/installing of updates. This covers most cases and installs updates on quit except for when auth is needed (think non-admin user accounts).

2. Don't make the update UI modal. You do not want to prevent the user from quitting your app, even during an install-update-on-launch workflow. Hide the rest of your app UI instead and wait until the updater is done (in both cases when update is found to be downloaded/installed and when an update is not found; there's probably delegate methods here). You may only want to check for updates during launch in this case, opt out of automatic checking for updates, and install updates automatically because you're not giving the user much of a choice anyway. Sparkle does not provide a good UI in this case (I'm thinking of an app logo banner shown like Discord which takes a long time to launch..), but 2.x lets users plug in their own custom UI / user driver, although I'm still revising the API.

[core-code]

One can disable closing the window (which is equivalent to remind me later)

how can we disable that? our users keep skipping the updates by closing the window even though they have sparkle:criticalUpdate set and we really need to prevent this. any ideas? thanks!

[zorgiepoo]

It's not possible without forking Sparkle and making adjustments in say, -[SUUpdateAlert windowDidLoad]. Presently as discussed above, this is expected behavior for Sparkle. Technically users can still ignore the window if it's not closable. Make it modal and you may introduce other problems (and experience tells me I'd like to get away from modal alerts when possible).

edit: well it's also possible to access the NSWindow in some obj-c reflection / fragile / not-exposed APIs sort of way

[zorgiepoo]

Maybe disabling the close button for critical updates is OK. edit: no.. I don't think so.

[core-code]

It's not possible without forking Sparkle

thanks for the info

no.. I don't think so.

why not? "critical" implies that the update is required and cannot be skipped.
thats why the "skip" and "ignore" buttons are removed. removing those but keeping the close button is weird IMO. like a job half-done...

would it be possible to make that change either by default or optionally (enabled by some delegate methods)?

going "modal" is definitely a bad idea though (for default behaviour in mainline Sparkle)

[zorgiepoo]

It’s like giving them a choice but not really giving a choice with the current wording as kornel mentioned in the linked issue.

if the user initiates an update check themselves, getting into a critical noncloseable window is kind of bad experience. If the user comes back to their app with some other work to do, it may be bad too.

Maybe the update alert needs to be less subtle it’s critical as far as messaging goes. Another idea making critical updates opt into automatically downloading and installing on quit (when possible) and still prompting (not sure how hard change would be to make and haven’t assessed if this is a good idea).

Potentially we could provide a private API that exposes the NSWindow of the standard user driver or something more specific. Likely care about the updater state, appcast item at least, maybe if it’ll be in immediate focus too. May be able to plug into the existing standard user driver delegate method for showing an update or add another more targeted one..

[core-code]

all our updates are manadatory. there is no choice. the app requires server support and most of the time if there is an update the existing version will stop working in one or two weeks anyway. so the only thing that leads to a really bad user experience is the existing ability for users to click the close button.

we don't want silent / background updates though as it is essential that people read the release notes.

i guess the only solution currently available in mainline Sparkle is just calling checkForUpdatesInBackground again if didDismissUpdateAlertPermanently gets called in response to the window closing. we'll implement just that for the time being.

[core-code]

unfortunately you can check for a user closing the window in Sparkle 1.x with the didDismissUpdateAlertPermanently delegate method but in Sparkle 2.x the userDidSkipThisVersion is not called when the user closes Sparkles window

edit: thinking about this it makes sense because the "skip" only happens when clicking the "skip" button... but it seems any way to look for non-permanent dismissals got lost in 2.x

[core-code]

the attached patch fixes a bug where userDidSkipThisVersion is not called because the relevant method passes skipThisVersion instead of SPUUserUpdateChoiceSkip

also it adds the new userDidDismissThisVersion delegates that can be used to learn if the user clicked "remind me later" or closed the window. the other option instead of introducing a new method would be to re-add the "permanently" parameter to userDidSkipThisVersion and call it with NO for dismissals and YES for skips...

fix-diff-patch.txt

[zorgiepoo]

the attached patch fixes a bug where userDidSkipThisVersion is not called because the relevant method passes skipThisVersion instead of SPUUserUpdateChoiceSkip

I'm not following this. The patch does not apply for me on 2.x or to any version of Sparkle I know (briefly looking).

also it adds the new userDidDismissThisVersion delegates that can be used to learn if the user clicked "remind me later" or closed the window. the other option instead of introducing a new method would be to re-add the "permanently" parameter to userDidSkipThisVersion and call it with NO for dismissals and YES for skips...

fix-diff-patch.txt

I think this is probably a fine delegate addition if you were to open a PR on 2.x

[zorgiepoo]

I added a task for dismissing callback #2250

I didn't see anything wrong with the skip callback, works over here.