- User Since
- Mar 3 2017, 7:23 PM (160 w, 5 d)
Thu, Mar 26
Sun, Mar 22
Fri, Mar 13
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
Apr 6 2019
Apr 5 2019
Mar 31 2019
Mar 3 2019
Feb 24 2019
Feb 20 2019
Ok, so let's abandon this approach and reconsider our options (see also update to b.k.o bug report)
Update commit message to track corresponding kdesrc-build issue in Gitlab on invent.kde.org
Feb 19 2019
Hmm, doing this produces a dependency cycle when you *don't* include qt5-build-include through your kdesrc-build.rc. E.g.: kdesrc-build --include-dependencies --no-metadata kio explodes with:
Fixed up commit message/bug tag.
Feb 18 2019
Rebased git history to get proper tags in commit messages.
With the last change bug #404486 should be fully fixed.
- Consider and prefer using tools from qtdir/bin and kdedir/bin if available.
The only thing missing is to adjust Util & Application modules, specifically the sub _checkForEssentialBuildPrograms in Application to consider qtdir/kdedir as well as $PATH (absPathToExecutable).
Possibly using a copy of the absPathToExecutable which takes an additional second @paths positional argument (list).