- User Since
- Mar 3 2017, 7:23 PM (178 w, 6 d)
May 18 2020
May 17 2020
With the move to gitlab/invent.kde.org it seems better to abandon this in favour of a straightforward MR using the new shiny :)
May 15 2020
May 14 2020
May 9 2020
May 3 2020
May 2 2020
May 1 2020
Apr 30 2020
Apr 23 2020
Apr 22 2020
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.
Apr 17 2020
Apr 12 2020
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.)
Apr 10 2020
Apr 6 2020
Mar 26 2020
Mar 22 2020
Mar 13 2020
Jan 12 2020
Jan 5 2020
Jan 2 2020
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?
Jan 1 2020
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.
Dec 31 2019
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?
Dec 28 2019
Oct 22 2019
Sep 30 2019
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.
Sep 24 2019
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
Sep 8 2019
Sep 7 2019
Aug 24 2019
Aug 20 2019
Aug 16 2019
Aug 10 2019
Apr 21 2019
Apr 17 2019
Apr 13 2019
@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