Automatically install curated Flatpak updates

[meisenzahl]

Closes #1446

[meisenzahl]

I tested this in a VM and unfortunately found that the update_available property is not true for packages that have updates available. I'll have another look at this.

[meisenzahl]

Seems to work now:

Peek.2021-12-12.21-12.mp4

[hanaral]

I really think that this should be implemented in a backend, where all the current in-app update management could also go (the app is already quite prone to locking up as is when loading updates
Edit: Also it should be off by default at least until the automatic updates can be affected by metered connections or blocklisted on non 'home' networks (a la iOS autoupdates)

[meisenzahl]

AppCenter is already running in the background as io.elementary.appcenter -s. If the package caches update is older than 24 hours, the Flatpak updates would be installed automatically in the background.

I am open to feedback from @elementary/ux on whether the automatically-install-flatpak-updates setting should be enabled by default.

[meisenzahl]

The status of whether the connection is metered can be queried via org.freedesktop.NetworkManager's metered property: https://developer-old.gnome.org/NetworkManager/stable/nm-dbus-types.html#NMMetered

We could implement the logic for this in a follow-up PR.

[hanaral]

@meisenzahl I mean that appcenter should manage updates along with installs as a seperate process (not subprocess) as proposed in #1471 (if anyone is willing to implement it)
Good to see a preexisting gsetting for metred connections, it would be even better if there was a allowlist gsetting for networks so it never does autoupdates besides user-set networks

[cassidyjames]

UX wise I agree this should be off by default until we can handle metered connections. At that point I think it would be safe to turn it on by default and/or prompt users to enable it.

If we can distinguish between "automatic" and explicitly-set non-metered (e.g. with NM_METERED_NO) connections, we could choose to do that, but I don't know if that's necessary.

[cassidyjames]

Another UX/security question I have: can we restrict automatic updates to curated apps? Automatically updating non-curated apps means apps could update with more sandbox holes that haven't been human-reviewed, which sounds like a bad idea. Otherwise I think we'd need to implement some sort off manual approval process if the Flatpak sandbox changes, which sounds even more complicated.

[meisenzahl]

@cassidyjames yes we could query if the connection was automatically or explicitly configured as metered.

The last push restricts automatic updates to curated apps.

[cassidyjames]

This should be the large toolbar size, but I know that's gonna require some styling fixes as well since we do weird things with margins/padding in CSS here (I think due to the updates badge overlay). I may have started addressing it in #1230 but I also know that PR is pretty outdated.

[meisenzahl]

Any suggestions on how we are going to implement this at this point?

[cassidyjames]

@meisenzahl actually in testing, using LARGE_TOOLBAR looks really close; we might just have to tweak the styling here to match other apps; it looks like 3px matches Files, at least, but I'm also not sure how we would get it to scale with the text-size like our rem() sass function in the stylesheet… 🤔 That might be over-thinking it, though, and 3px here might be fine.

appcenter/data/styles/application.css

Lines 18 to 21 in c9d9f16

	.titlebar {
	padding-bottom: 0;
	padding-top: 0;
	}

[meisenzahl]

Using LARGE_TOOLBAR and 0.188rem for padding:

[mcclurgm]

If I may add a UX thought, it may make sense to place the switch at the top of the "Installed" tab, instead of being the only entry under a gear menu.

Since it's about the updates that appear in that tab, to me it's a natural fit there, and not in the home tab where it's also currently visible. That would also make it more visible, so it would kind of implicitly prompt people to enable the setting without adding an explicit dialog.
Having the switch always present may be unnecessary clutter, though.

[cassidyjames]

@mcclurgm that might be fair considering it's the only item in that menu, but we've been talking about adding a menu for some time, e.g. for the items in #1230 or even for the refresh/fetch action from #1791. I would be okay moving to a menu in anticipation of those actions.

[cassidyjames]

Some naming nits, but this looks pretty good to me.

My only other question is: since we're reading the GSetting multiple times in Client, does it make sense to read it once and cache its value, or is it fine to read it multiple times?

[cassidyjames]

I can't confirm this is actually automatically installing curated Flatpak updates. I toggled the setting on, then manually downgraded Dippi (e.g. with flatpak update --commit=b826d7d99eb010f63c60405404363386e66ffcf83b1ce55f0e3fbed8634589e4 com.github.cassidyjames.dippi). AppCenter still shows the update as available, but as far as I can tell, won't install it automatically.

[cassidyjames]

Ah @meisenzahl I see now that this is using the last refresh time to avoid auto updating all the time. That's smart, and by resetting the refresh and restarting AppCenter, I can confirm the update was automatically installed.

[cassidyjames]

Alright, I think I just have one last @elementary/ux question: how do we treat paid apps that were installed for free? Traditionally, we treated these a bit differently to re-prompt the user to pay. Should these be excluded from automatic updates like they're excluded from the "Update All" logic? My inclination is yes, but that makes it harder to explain in the app.