GitLab

On some cases we were passing the wrong installation and it broke our
installation.
It's better to just rely on the installation that the resource already
knows it has.

There is no need for it. Makes the operation more expensive and it makes
the output too verbose when there's problems.

So we don't block on it.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

See https://github.com/fwupd/fwupd/issues/2600

Ports to fwupd_client_refresh_remote which also simplifies a lot our
codebase.

GIT_SILENT

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

Otherwise it will be blocked correctly by window manager focus policies

BUG: 423857

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

flatpak_installed_ref_get_appdata_name returns utf8 string, using
QLatin1String would cause displaying invalid string in UI.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

Makes it possible to trust the running distribution or fleet admins to
offer the right thing without having to go through pointless GUI steps.

Respect the users' regional settings.

On Mobile, the common and expected behavior is pulling down the view to
refrehs it, so we don't need to show an explicit button.

People seem to feel that the Update action should be the right-most one
in desktop view. This commit accomplishes that, without changing the
ordering in mobile/narrow view, which would inappropriately cause the
Refresh action to be the center one in the floating action button.

BUG: 422630
FIXED-IN: 5.21

This allows the Addons view to use entirely standard components rather
than a homegrown implementation.

This increases the Frameworks dependency version to 5.78 since that's
the version that includes Kirigami.CheckableListItem.

Depends on frameworks/kirigami!185

Adds a tooltip to the "Fetching updates..." label so that users can know
what's holding the update back.

Keeping it in a tooltip since it's something that never should be seen,
except when there's a problem somewhere in the system.

It's not used elsewhere and skips the creation of a weird intermediary
container.

The Home tool button isn't available there as it's in the search toolbar
generally. It used to be on the banner but that went.

We need to know when the offline update has been triggered, We were
listening to the wrong object though and it was erratic. Now it will be
checking the triggered value correctly.

It will work for backends that specify it.
For now just PackageKit supports it.

BUG: 425691

The UpdatesPage will also do it, and so will the notifier. No need to
have it everywhere.

Otherwise we get a weird floaty restart button during the updates are
still in progress.

It feels weird to read the "computer" when you're on a mobile phone,
even if it's not entirely wrong.

Otherwise it was shown when hovering the page randomly.

Otherwise they stay lingering forever giving the impression that it's
stuck.

BUG: 418082

Which streams are holding us up?

Some test cases rely on a clean .qttest, so make sure it is.