Now that was fast. Thanks for the fast reply. Trying arc land...

I'll also update the commit message before I push this; my local changes somehow didn't make it through arcanist.

Added column names explicitly

In T6854#107619, @mlaurent wrote:

Where is the header from folderview? If we don't have it we don't have access to column settings as "size icon" as "show unread"/show size etc. We can't hide/show tooltip etc.

+1 for any attempts to modernize Kontact, and of course for even starting a discussion about it!

Yay, I used arcanist to create a review request for the first time!

What happens if the user sets the color back to default? We wouldn't get past line 760, and disableColor() wouldn't be called, so the color would not be saved immediately, right?

In D7285#135693, @mlaurent wrote:

yep but here we didn"t use data from wizard so I don't see where it can crash

Objects that live on the stack should not be subject to heap memory management; something that definitively hasn't changed. Memory management in Qt is already quite confusing. This change supports local reasoning about the code. This easily outweighs the micro performance hit.

So now we have readability, memory safety and performance on the plus side. To further back my performance claim, [1] investigates the difference between stack and heap allocation. Short answer: depends on the platform, but stack allocation can easily be faster by two orders of magnitude for a simple single-threaded program. KMail is multithreaded, so we can expect bigger differences: Heap allocation causes threads to synchronize on most platforms, because the heap is a shared resource (see e.g. [2]). The kind of allocation also hints at the expected lifetime of an object (in C++; in Qt, this is somewhat questionable).

Thanks a lot for supporting my application!

I still don't have write access, so it would be nice if someone could commit my 8 accepted patches (or help me get a Developer account).

But we still save an inefficient heap allocation. That's already useful in itself. And there's really no point in creating this QMenu on the heap here.

The reasoning is the same as in D7107. Additionally, we can see here how it simplifies memory management and prevents memory leaks: In line 2756, we had to remember to delete menu before we return. We can easily forget that, and now get it for free.

Yes, I saw the optimization for types that are not ::isLarge, but we still require the array. And your auto version removes the last three heap allocations, which is great. I'll update my diff accordingly.

It's the size of the container itself (and its heap allocations) that we reduce. The old code constructs an empty array list, and then calls operator<< n times. For every such call, QList allocates a new array on the heap, one element larger in size than the last one, and then moves the old contents to the new location. That's what I figured out by looking at QList's source code (QList::operator(t)<< calls QList::append(t) calls QListData::append() calls QListData::append(1), which does exactly what I just described) , but maybe I missed some mechanism that batch allocates more space than needed, just as QVector does. But even if it did, QList cannot know at the beginning of the << sequence how much space it would need eventually. So even with vectors' trick to allocate some constant fraction of the previously used amount of memory when size hits capacity, we would have log(n) memory allocations for n insertions. Using the ctor directly reduces this to only one heap allocation.

We save one heap allocation. Stack allocations are always cheaper. Also, we reduce the risk of a memory leak, when for some reason the "delete menu" isn't reached.

You are right, we don't need qAsConst, since operator<< already takes a const&.

With raw pointers, we have no way of telling if an object on the heap was deleted by its parent. On the other hand, QPointers are reset to null, which is easily detectable. The Q_ASSERTs make sure that everything was deleted as intended, and they would not work with raw pointers, because they would definitely still point to the location where the deleted objects were once created.

Oh yes, you are of course right! Looking at other uses of QDialogs and all these checks "if (... && dlg)", I assumed that QDialogs destroy themselves eventually, but they don't.

I tried to motivate the move from raw to QPointers with the memory bugs I found. First, mTreeFolderWidget was not reset to Q_NULLPTR after it was deleted, although this pointer is used in nine places in kmmainwidget.cpp to check if that widget exists, and to access it afterwards. Second, mFolderModel was reset to Q_NULLPTR in deleteWidgets, although it was not destroyed there, so that model leaked. Both problems would not have happened with QPointers. The Q_ASSERTs help find such wrong assumptions that we rely on now.

In D2599#48516, @mlaurent wrote:

It doesn't work when I implemented it.

Please note: I changed the type of some KMMainWidget members to QPointer<>. I wasn't entirely sure if this requires a PIM_VERSION bump again. Please tell me if it does.

Marked inline comment as done

Fix what was asked for. I assume it is sufficient to change the PIM_VERSION in the CMakeFile.txt of calendarsupport only, since PIM_VERSIONs between pim modules are already diverging.

I don't have commit access. Would someone please push this for me?

Just a slight simplification

I adapted kolab's approach of a member variable for missing categories, which now also makes sure that a categorie do not get lost if the server could, for whatever reason, not create the corresponding missing tag.

In D2423#45545, @knauss wrote:

We also did this on kolab branches already:

https://git.kolab.org/rKPbecae4738c14ef

It seems QString is just as hashable as QByteArray :-)

The original methods of TagCache were restored in order not to break old code that relies on it. In order to avoid name-gid collisions and because of the fact that clients know whether they want to match gids or names, we maintain separate methods for the tag name and gid caches.

I tried to implement all of knauss' remarks, but I encountered a race condition problem:

Just noticed: it should also fix Bug 357236