With the move to gitlab/invent.kde.org it seems better to abandon this in favour of a straightforward MR using the new shiny :)
See: https://invent.kde.org/plasma/plasma-nm/-/merge_requests/1

In D29095#655214, @ngraham wrote:

FWIW all the mice in my house have this exact shape, but they're black, not gray. So I don't think the shape is too old-fashioned per se. It's the gray color that's anacrhonistic part, since it's a very 90s/early 2000s color and modern mice tend to be black:

In D29095#655060, @saligari wrote:

Maybe this is just me but the overall width to height ratio makes it seem that the closest "real" mice are quite dated as well.

I don't understand what you mean with this, do you think it should be slimmer? I kind of followed the old one in this, even if it doesn't seem like it. Right now its ratio is ~0,67 while microsoft's standard old mouse is kind of close to that (but has a different shape)

One thing I find really striking about the new icon is how closely it resembles stress balls:

Hmm, the old icon also has the virtue of looking more like genuine computer mice: it resembles the logi(tech) & copycat style of mouse design quite well in a stylised sort of way. It's got the side buttons, the smooth/fast scrolling thing and managed to capture the ergonomic mouse shape. It's also got colour accents.

General comment: your patch might fix this, but there is no source code comment explaining things *must* be added sorted on key order and the code still does not enforce this invariant either. (Which makes a comment about it all the more important.)

Cleanup.

Superseded by: https://phabricator.kde.org/D26367

Are we certain about naming here: SwipeAction.isDelete? Maybe SwipeAction.collapse ? It doesn't necessarily have to be a real "delete" action that is backing this, maybe all you want to convey with the name of this setting is that the list entry will be collapsed in an animation?

Right now the KCM CmakeListst does stuff like:

If I understand "the Neon position" correctly here, Neon aims to be the base OS + Plasma desktop. The only reason it still bothers with packaging apps is because it has to because nobody is going to use an empty shell, and the Linux world isn't all app-ified yet.

Fixed commit message typo

As far as I am aware our flatpaks are purely packaging formats and don't take advantage of any sandboxing features. So I don't see what is there to recommend our flatpak implementation over our snap implementation, say. But then again, that could be part of this: pushing the packaging forward.
On the other hand: has anybody asked the application developers about their opinion on this? After all, they will be expected to take on additional maintenance efforts to make sure their app continue to work well with the chosen packaging format and they might just have opinions on that.

Rebased onto latest master

This completely alters one of the core propositions of how a Kirigami UX works. I may be mistaken, but if I understand it correctly drawers are supposed to be accessible via buttons. If gestures conflict, why remove page row navigation by gesture rather than drawer gestures?

Also side note, as a non-native English speaker I find "grossly" to be a bit of an odd adjective to use here -- "coarsely" would be more familiar: as in fine/coarse grained. Perhaps something to keep in mind when this lands and you start blogging about it :)

Ideally you would also warn if the reciprocal times the horizontal, vertical resolution yields a non-integer output, not just if some value is chosen which cannot be represented in floating point exactly.

And if so, sure I can 'fix' this by downgrading to QQC 2.4 instead but in that case: is this 'safe'? I.e. does this introduce bugs/regressions?

If Kirigami is supposed to depend on Qt 5.11, then *why* were these old imports there in the first place? They cannot work with Qt 5.11, because then the max QQC version is 2.4

In D20279#451615, @bcooksley wrote:

This looks fine to me, subject to being okayed by @mpyne

Only thing I do see is Qt5 being changed to third-party/Qt5

@bcooksley is this more to your liking now? I used the third-party/ prefix to mark non KDE modules.

Fixup search & replace breakage.

Fixup for gpgme -> third-party/gpgme

Fixup for search & replace breakage.

Introduce the third-party/ prefix like bcooksley requested

In D20279#444164, @bcooksley wrote:

Would it be possible to have all the external items sitting in their own namespace?