GitLab

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"

As the subject suggests, this fixes the icon being cut off due to
overflow being clipped. This was caused by an inconsistency in the
layout (the installed badge does not have the margin)

FIXED-IN:5.80
BUG:433535

This is called whenever we open the dialog, but we do not want to emit the signal unless
we actually clear this list. Otherwise the KCMs would reload their data and scroll back to the top.

Also we do not want the changed signal to be emitted for intermediate states,
this will only lead to noise on the KCM side and we still emit the signal when we
have the entry updated/installed.

BUG: 431568
FIXED-IN: 5.80

If we never want to scroll to the top we have to implement this on the
side of the individual KCMs.

If you want git blame to ignore formatting revisions run:
git config blame.ignoreRevsFile .git-blame-ignore-revs

Prevents some uglification and makes rebasing a bit easier.

Without this patch, the dialog's bottom is covered by the drawer's
handle, which makes it awkward to get to specifically the close button
(but also it just looks very strange). So, using Kirigami's nice, new
canContainHandles property on the global toolbar, we put the handle up
there instead. It also looks nicer, which is... nice.

GIT_SILENT

This hides the spinner and makes sure the search field is disabled when the engine is invalid.

Otherwise the application would crash, which should not happen in any
case.

BUG: 402432
FIXED-IN: 5.80

See sdk/kdesrc-build!82

GIT_SILENT

There components have been on life support for a long time
and most of the consumers are already ported to QML.

For the remaining QWidgets applications the KNS3::Button can
still be used and the recently added KNS3::QtQuickDialogWrapper class.

The knewstuff-dialog does this job far better and does
not use deprecated components.

This removes the custom header implementation used on KNSQuick's Page
component, which was originally implemented because Kirigami did not at
the time support the granularity of control needed to do the stuff we
wanted to be able to do. Now that this has changed, it was time to do a
refactor and move the things into context actions that make sense to
move there (which, essentially, is everything but the category
selection, since that one is more type dependent, and arguably a part of
the content of the page).

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"

The stars are great for at-a-glance viewing and interaction ability (for
future rating submissions), but having a label which displays exactly
what the rating actually is, in numerical format, is just kind of nice.

Kirigami.Units.gridUnit * 65 x Kirigami.Units.gridUnit * 40 evaluates to
1170 x 720, which is pretty huge with the default font size, and even
bigger for a larger font. It doesn't need to be that big to be usable;
let's reduce it a bit.

GIT_SILENT

Before this was done in the button, but it was not
called in the QtQuickDialogWrapper class.

This adds in support for the kns URLs used in e.g. kpackagetool to
canonically reference a specific entry found on a knewstuff provider.
The result is that by passing in such a URL to the knewstuff-dialog
tool, we interpret this as wanting to show the details for that specific
entry.

The origin of this functionality was a short discussion on
plasma/discover!63 where the
need for such functionality became obvious.

CCBUG:430812

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"

As identified by Piotr in the bug mentioned below, Discover simply
returns an invalid response for any Question forwarded to it. The result
is that any update which fails to identify an update automatically will
fail due to not having payload which should be used for updating identified.

This patch fixes part of the issue, by resetting the entry for which no
payload could be identified to Updateable rather than leaving it in
limbo as Updating.

This does not fix the bug in Discover, but it does at least alleviate
the issue (it still leaves entries in Discover, rather than updating
them, but without having a way to forward that question to the user,
there's not a lot to be done about that other than output an error
message with instructions to use the GHNS dialog to do that particular
update, which of course is not exactly up to par... so, not closing the
bug with this, the issue in Discover still needs sorting out... somehow).

CCBUG:430812