Conversation
This actually making me wonder why there isn't a "Cancel All" button to help instead of having to click Cancel for every app that is waiting to update |
|
you actually don't have to click cancel for every app, you only have to click cancel for the app that is currently updating which will automatically drop out of the update loop. you can't even click cancel for the other apps since they aren't updating yet and their buttons should be insensitive or do you observe some different behavior? |
|
I must be remembering old behavior! Just confirmed you are right. Sweet! |
| } else { | ||
| update_manager.cancel_updates (true); | ||
| // TODO: Follow up: think about this? Only update all and handle in manager? | ||
| update_manager.refresh.begin (); |
There was a problem hiding this comment.
Yeah I agree we should just listen for the gsettings change in update manager
danirabbit
left a comment
There was a problem hiding this comment.
This all makes sense to me. I think we probably will want to replace those timeouts with a systemd timer like we did here: elementary/settings-daemon#200
I just have a couple of minor comments but nothing blocking. Happy to merge this. Nice cleanup :)
This PR streamlines the refresh flow. We now do everything in the update manager which will automatically start the timeout if we're less than 24 hours from the last update or else refresh immediately.
We also now only refresh after the network comes available if we tried to refresh while the network wasn't available.
This doesn't include but prepares for more behavioral changes proposed in #2214
Also prepares for some cleanup of the refresh action enabled logic which is left to another PR
cancel_updateswas removed because it was only used to cancel updates