Version: 1.9.50 (using KDE Devel) Installed from: Compiled sources OS: Linux This occurs for both gmail imap, and a local cyrus imap account. Triggering a check mail in folder results in the progress reaching 95% "Getting quota information", and then staying in this state until cancelled.
My guess is that this is the incorrect connect the compiler complains about, in quotajobs.cpp (actually the compiler complains about an overloaded virtual, but that is the same issue basically) I don't know enough about IMAP yet to fix this myself. Ryan, do you want to have a look? Your last patch already was great, it would be good to get more developers.
Hi Thomas, I had a quick look and thought the same, seems to be one of the callbacks failing. I'll take a look tonight and see if I can figure something out :)
Hey all, I've been investigating into this bug am I quite confused. The QuotaJobs::GetStorageQuotaJob isn't emitting the result signal which causes the KMFolderCachedImap object to progress the progress. Fixing up the broken signal didn't make a difference. It seems the result() signal is emitted when the emitResult() function is called however this was removed in revision 527075 (http://websvn.kde.org/trunk/KDE/kdepim/kmail/quotajobs.cpp?r1=504943&r2=527075) as it was emitting duplicate signals. Does anyone know more about the KIO::Job class to tell me if you need to call the emitResult() function manually, or does this class somehow trigger this automatically? Ryan
I don't know much about the job classes myself. Here are some observations. As I don't have IMAP myself, I can not test anything. Maybe you can put together the pieces. 1. KCompositeJob already has a slotInfoMessage function, which is even virtual. These could mean that the slotInfoMessage in QuotaJob is supposed to override that. Also, the signature of slotInfoMessage changed: Before, it was in another class (in jobclasses.h) and had only two arguments, now it is in KCompositeJob (which is new) and has an additional argument http://websvn.kde.org/?view=rev&revision=558448 http://api.kde.org/4.0-api/kdelibs-apidocs/kdecore/html/classKCompositeJob.html 2. In the enterprise branch, which probably works correctly, there is also no emitResult. See http://websvn.kde.org/branches/kdepim/enterprise/kdepim/kmail/quotajobs.cpp?revision=631694&view=markup >Does anyone know more about the KIO::Job class to tell me if you need to call the emitResult() function manually, or does this class somehow trigger this automatically? Till told me it is emitted automatically. You can probably place a breakpoint in slotQuotaResult of kmfoldercachedimap and find out when it is emitted (using the 3.5 or enterprise branch). I think (but I might be wrong) that slotInfoMessage is supposed to be called automatically whenever a subjob emits the infoMessage signal. See the code for KCompositeJob::addSubjob, which does that. That would explain why it doesn't work in QuotaJob, since that wasn't adopted to the new slotInfoMessage signature. I do wonder why a connect for infoMessage/slotInfoMessage is done in QuotaJob at all then... Generally I suggest using GDB to debug the problem. Place a breakpoint in slotInfoMessage and see if it is called at all. If not, find out why...
This bug makes kmail unusable with IMAP accounts, so I'd like to request it be fixed ASAP.
*** This bug has been confirmed by popular vote. ***
same here.. imap unusable.
*** Bug 157744 has been marked as a duplicate of this bug. ***
SVN commit 778618 by tmcguire: Don't get stuck when receiving quota info for dimap. A emitResult() was missing. BUG: 154960 M +5 -8 quotajobs.cpp M +1 -10 quotajobs.h WebSVN link: http://websvn.kde.org/?view=rev&revision=778618