Delay initial check for updates by default 60 seconds

[vjr]

Related to:

elementary/settings-daemon#158

and

elementary/settings-daemon#177

[danirabbit]

AppCenter no longer uses PackageKit so I'm not sure this is still relevant here

[vjr]

AppCenter no longer uses PackageKit so I'm not sure this is still relevant here

The intent is to delay the flatpak check too - does this PR still make sense?

[danirabbit]

I'm not sure what problem you're trying to solve here with the Flatpak side of things. It seems like you should either turn on automatic updates in appcenter or disallow appcenter from auto starting so you can run Flatpak updates manually in terminal. But I'm generally not a fan of adding magic number timeouts to things

[vjr]

There's already a SECONDS_AFTER_NETWORK_UP constant in here - not intending to add a magic number.

Wanted to (re) solve the (I guess) regression mentioned in elementary/settings-daemon#158 which are the old issues #495 and #721 which is to not hog the system/network as soon as you startup/login.

Let me know if this is sufficient rationale for this PR - otherwise no worries - we can close/drop this one :-)

[danirabbit]

I think in that case it would be better to do something like check for available resources/user activity instead of using a timeout

[vjr]

I think in that case it would be better to do something like check for available resources/user activity instead of using a timeout

argh! that sound like a mini-project on its own lol. can that be a feature/wishlist item for a later time?

just a reminder this is just bringing back the previously accepted workaround mentioned in this comment but in the code instead of that old config key - im not sure if the old way is still valid.

[vjr]

PR elementary/settings-daemon#200 reminded me of this old PR, it was approved but just requesting re-review from devs as a followup if it's ok to merge?

[leonardo-lemos]

LGTM — the timeout is implemented in a clean way and fits well with how the issue is being handled here.

[leonardo-lemos]

I think in that case it would be better to do something like check for available resources/user activity instead of using a timeout

@danirabbit Can we go ahead and merge this for now, and leave that feature for a future implementation? I see this as a quick win, while implementing a full user activity monitor to trigger updates would be significantly more complex.

[danirabbit]

I'm personally against adding a fixed timeout here. In practice this just ends up with all our services running at the same time but with a delay after startup. Another solution would be using a systemd unit. Systemd has a mechanism for staggering scheduled events built in

[leonardo-lemos]

I'm personally against adding a fixed timeout here. In practice this just ends up with all our services running at the same time but with a delay after startup. Another solution would be using a systemd unit. Systemd has a mechanism for staggering scheduled events built in

@vjr I agree with Dani's suggestion — using Systemd should be straightforward, as it only requires setting up a timer and allowing AppCenter to run the update check via the command line.

[vjr]

thanks for the ideas but i might not be able to dedicate time to work on the systemd approach, maybe someone else like @ryonakano could try especially since they're already working on elementary/settings-daemon#200 ?