https://bugs.kde.org/show_bug.cgi?id=323929
--- Comment #34 from Christian Mollekopf <[email protected]> --- I'm not sure the applied fix actually fixed the actual problem, since the use of Qt::UniqueConnection was IMO just fine. The applied patch just disconnects slotDefaultCollectionsChanged, which it probably shouldn't as we want to get updates for changed default collections. It of course works around the problem of the loop, but probably introduces a new bug. Here's the analysis from thiago from 323068: 1) when KMail starts, I suppose MailCommon::Kernel::initFolders is called to initialise the folder listing 2) MailCommon::Kernel::initFolders creates a Akonadi::SpecialMailCollectionsDiscoveryJob job (derived from Akonadi::SpecialCollectionsDiscoveryJob) 3) when Akonadi::SpecialCollectionsDiscoveryJob finishes, Akonadi::SpecialCollectionsDiscoveryJob::slotResult is called 4) Akonadi::SpecialCollectionsDiscoveryJob::slotResult iterates over the result (201 folders). For two folders, it calls: 68 d->mSpecialCollections->registerCollection(collection.attribute<SpecialCollectionAttribute>()->collectionType(), collection); The two folders have mRemoteId = "outbox" and mRemoteId = "caixa de saída" (don't ask me why one is localised and the other isn't). 5) because of those calls, Akonadi::SpecialCollectionsPrivate::emitChanged gets called 6) since those two folders have resourceId == mDefaultResourceId, the defaultCollectionsChanged() signal gets called, which ends up calling MailCommon::Kernel::initFolders 7) repeat ad nauseam -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Kdepim-bugs mailing list [email protected] https://mail.kde.org/mailman/listinfo/kdepim-bugs
