In D16509#352607, @dvratil wrote:

assuming DAV actually supports that.

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?

In D16557#352074, @dvratil wrote:

Would you mind changing that, since you are touching the tests?

Removed Q_UNUSED(argv) from Windows build

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.

In D16508#351114, @ochurlaud wrote:

If it is just factoring, you can ship it. If not, I'd like to be sure not to miss anything in the change.

I just discovered by accident that I was named reviewer for the first time. Didn't see it coming!

• Increase Akonadi DB scheme version

Discoverability trumps ;-)

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.

In D16114#340904, @winterz wrote:

void KTimeComboBox::timeChanged (const QTime & time) [signal]
    Signal if the time has been changed either manually by the user or programatically.
 
void KTimeComboBox::timeEdited (const QTime & time) [signal]
    Signal if the time is being manually edited by the user.

to me that reads as if timeEdited isn't needed if you are using timeChanged. but .. heck, what do I know?

Forgetting consts in a Diff that is motivated by added consts. Nice! ;-) I added them.

• Add missing const qualifiers

Another thing I just noticed: You use border width 1 unconditionally, when it was 2 unconditionally before.

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.

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.

@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.

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?

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?

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.

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?

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.

In T7891#126576, @knauss wrote:

I think the best approch sofar is to use pointers to incidentence and not using the UUID at all on the code.

For everyone except @dvratil: Dan's comment is referring to my following thoughts:

In T7891#126568, @knauss wrote:

Akonadi can't change the UID (if you meen the UUID from ical), cause this is needed to be exactly the same when you do meeting etc. where you send eventes around.

Now that I reread my comments, they sound more aggressive than I intended them to.

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...

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.

And of course, yay for the Tag docs! That's much more text than I expected

In D7548#140147, @dvratil wrote:

I created an event in KOrganizer, gave it a bunch of categories and saved it. Then I edited the event, changed some parts and added some more categories and I did not see any GID-named categories being created. Did I miss some steps?