Feature request: delay update prompt when fullscreen apps are visible

[herf]

f.lux user had update prompt during movie playback.

See screenshot from here:
https://forum.justgetflux.com/topic/3698/update-popup-very-inconvenient

Fullscreen "spaces" can be detected like this (but I have not made a patch like this for Sparkle):
http://stackoverflow.com/questions/23896803/os-x-detecting-when-front-app-goes-into-fullscreen-mode

[kornelski]

That definitively looks bad.

The detection code on SO seems a bit hacky, and I'm not if it can be relied on. I wouldn't want to accidentally hide all updates in case it gives false positives. But perhaps delaying window once would be safe enough?

I was also thinking about using system notifications instead: #924 - that would work with the 'do not disturb' mode and other ways macOS itself avoids annoying people.

If there was an option to always use these notifications first, would that solve the problem for you?

[herf]

(Detection code doesn't work with multiple monitors in my experience.)

I wonder if there is an API for "do not disturb" that is simpler for this.

System notifications could add a click if you wanted people to see the update notice, but otherwise this sounds great.

[symmetriq]

This does need a solution. Sparkle update windows rudely pop up over top of presentations and games ALL THE TIME. Really annoying and frustrating. Makes me want to disable automatic update checks in every app that uses Sparkle.

[kornelski]

Added support for Do Not Disturb: 7a30cca92cb222d7079126387530fc972c712de0

[zorgiepoo]

DND apparently no longer works correctly.

This is a problem for backgrounded apps that use Sparkle. Backgrounded apps need to be more conscious about when presenting automatically scheduled updater alerts (like eg only when the app is launched / system is booted) and I don't know if there is a good heuristic Sparkle can use automatically honestly. Notifications can be a supplement but not a primary mechanism. Other apps going fullscreen is merely a subset of the root issue and DND support is a distraction to the problem.

[kornelski]

We could use OS-provided notifications (BTW, is there a way to detect that a notification hasn't been shown?), but OTOH macOS now requires explicit opt-in for notifications, and users are suspicious of these :(

[zorgiepoo]

I don't think we can present notifications such that we can rely on them actually getting delivered (users could turn them off for example). Then there is also the problem of automatically opting applications into them as you state. There was some old discussion in #924

I honestly would prefer backgrounded apps (like Karabiner as one good example in #924 apparently) disable scheduled automatic update checks and only check for updates on launch, or maybe system wake, or otherwise intelligently.

[herf]

I do like "at reboot" and "after standby" (but only once per update interval). Better to avoid interruptions, even independent of DND.

On the other hand, if you have a bunch of sparkle apps and have not booted a mac in 6mo, seeing all of them at the same time could be kind of terrible. (Some kind of global mutex for sparkle instances to coordinate?)

[zorgiepoo]

I'd like to generally avoid (and remove even) global sort of files / coordination like that.

Several apps being coalesced to show updater alerts around the same time is something that is sort of already present. A Mac not used for weeks may have that problem regardless, as well as a Mac that has been asleep for a while. (Although if you ask me personally, I think I'd prefer to get them all at once).

I don't know if "after wake" actually feels right or is still intrusive btw, but may be something worth experimenting around. I used to be an active user of Karabiner and felt that first-boot / after system boot was OK (to me personally) with sometimes also other application windows being restored simultaneously.

Some backgrounded apps may also present windows that user interacts with often and may afford more opportunities to present updating alerts, or may desire a custom UI tailored for the app (which 2.x makes more possible anyway).

[kornelski]

We do have a global-ish lock already (write a lockfile to tmp to help 3rd party updaters avoid clashing)

Personally I reboot only when Karabiner stops working ;) Update on reboot is definitely not frequent enough. It's also easy to miss windows in the chaos of macOS restoring all previously open apps.

[zorgiepoo]

We do have a global-ish lock already (write a lockfile to tmp to help 3rd party updaters avoid clashing)

Side note: It's more of a hint than a lock. But this is one thing that doesn't make sense to bring over to 2.x so I don't consider it long lived because it supports running multiple updaters and uses a 'central' agent/daemon installer service for a specific bundle that updaters can query. (Moreover, updates are supposed to be atomically installed anyway). Anyway that lock file is really per-process not across multiple applications.

[zorgiepoo]

Anyway I am sort of leaning towards it makes more sense for the application to be in control when is a good time to present updating since Sparkle may not know all the application's use cases (and maybe sparkle needs to offer some support here like deferring the scheduler). [edit]: well, sparkle already provides -updaterMayCheckForUpdates delegate which helps.

[zorgiepoo]

#924

[zorgiepoo]

@herf implementation in 2.2 (beta) has landed to fix this: #2158 - background running apps cannot randomly steal focus now and may want to consider gentle reminders. Further discussion there.