User Details
- User Since
- Aug 12 2016, 9:38 AM (403 w, 3 d)
- Availability
- Available
May 8 2020
Nov 2 2018
Nov 1 2018
Replacing Q_FOREACH with range-based for actually might change performance, in case the data structure detaches. Basically, Q_FOREACH creates a const copy of the container and iterates over that, so no detaching happens.
Use parens for non-default ctor calls with explicit type
Pass by cref instead of values in ctors
I also fixed the initialization order of ExpectedSignal's members.
Added seven consts
arcanist complains that this Diff has not been accepted. In general, should I wait for positive feedback from the same reviewer after all requested changes from this reviewer have been fixed and accepted by another reviewer?
Removed Q_UNUSED(argv) from Windows build
Oct 31 2018
I'm currently playing around with some tests, so how well are existing tests isolated overall? Is it just the identity tests that mess with my actual configuration? Where would I find those tests? I'd like to avoid running them.
It's that time of the year again: Why does KDE PIM have its own versioning scheme? We know there are reasons to just stick to the KDE Applications versioning scheme, but to this day, no one gave a reason not to.
I just discovered by accident that I was named reviewer for the first time. Didn't see it coming!
Oct 27 2018
Oct 11 2018
- Increase Akonadi DB scheme version
Oct 10 2018
Err... can I already push this to Applications/18.08? We are currently in the short period between 18.08.2 tagging and release. No idea if pushing now would have any consequences.
Forgetting consts in a Diff that is motivated by added consts. Nice! ;-) I added them.
- Add missing const qualifiers
Oct 9 2018
Another thing I just noticed: You use border width 1 unconditionally, when it was 2 unconditionally before.
Oct 8 2018
The margin helps to immediately grasp that the event starts/ends on that day, just like the radius. I think there should be a margin iff there is a radius.
Jul 22 2018
Added 5.8.3 to the [1] products from my last comment by hand; deactivated all versions of those products that are not 5.7.3, 5.8.3, git, unspecified or enterprise.
Jun 19 2018
@tillschafer approached me today: He wanted to report a bug for kmail2-5.8.2, but the version was missing. I added that version for all PIM products (I could think of [1]), and additionally a mix of versions 5.7.0, 5.7.2, 5.7.3, 5.8.0 and 5.8.1 for each product. Someone added some versions for some products, but not systematically at all. Some had 5.7.1, 5.7.3 and 5.8.1 set, while others had 5.7.0, 5.7.1, 5.7.2 and 5.8.1, and so on.
Jun 18 2018
The first proposed approach is just an External Payload without the need to cache the local file, but referencing it directly, right? So in other words, can External Payloads be viewed as Foreign Payloads + caching of the actual payload in a file?
Jun 15 2018
The move from Backlog to Done means that this is finished, and Monitors do not need the extra roundtrip to retrieve the changed Item, right? Was it just not closed by accident?
Feb 26 2018
Feb 22 2018
Feb 18 2018
Feb 17 2018
A solution for the multiple-instances-of-the-same-UID problem might be this: For every UID, there is a unique model index. However, we add a way to ask them for their containing calendars/collections. For example, we could add some ContainingCollections role, or an additional column, that reports a vector of collections. A view could then decide to
- display an array of symbols/colored rectangles, one for each collection that contains the task, and
- report conflicting information in multiple instances of the same event (e.g., the same task in two calendars, but with different parent tasks) in some way.
I fought my way through some messagelist code yesterday, mostly model(_h)?.* and item(_h)?.* I think they solve (many problems at once and) some of the problems that IncidenceTreeModel solves, too, but totally differently. I have a vague design in mind right now that might be used by both, but before I continue working it out any further, I have a few questions.
Feb 13 2018
The problem of kmail being equipped with new versions automatically instead of kmail2... would that have to do with the fact that it is "kmail" in the repo-metadata repo?
Feb 10 2018
I removed 5.7.3 (where applicable) and added 5.7.2 (where sensible) for: Akonadi, akregator, kaddressbook, kcalcore, kcalutils, kcontacts, kholidays, kimap, kmail, kmail2, kmailtransport, kmbox, kmime, knotes, kontact, korgac (added 5.7.1, too), korganizer, ktnef, syndication.
I'm afraid someone's currently doing a suboptimal job at this. After the 5.7.1 release, I noticed that 5.7.1 was added to "kmail" (sic!) in Bugzilla, but not to "kmail2". Now I think that some more products should have been equipped with 5.7.1, too.
Feb 5 2018
For everyone except @dvratil: Dan's comment is referring to my following thoughts:
Now that I reread my comments, they sound more aggressive than I intended them to.
Feb 4 2018
I just wanted to have a quick look at the message threading code to see if it might possibly introduce cycles. It is roughly from model.cpp:2067 to model.cpp:3361, 1300 lines of untested, untestable, deeply nested code with 13 FIXME comments in it, right?
How can a check *after* the recursive call resolve an infinite recursion? To prevent those, we have to treat base cases *before* the recursive call. Otoh, it seemed to help in your case. I'm quite curious how that's possible...
Feb 2 2018
Err... no, sorry for the delay. I finally found some time to spare on KDE again, but it's too late for 5.6.1 now, I'm afraid. We are some days clear of 17.12.2 tagging, so is it OK to push this to Applications/17.12? I rebased to that branch and re-tested today, of course.
Aug 28 2017
Aug 26 2017
Aug 25 2017
And of course, yay for the Tag docs! That's much more text than I expected