Bug 288140

Summary:	No visual feedback on the progress of moving folders
Product:	[Applications] kmail2	Reporter:	Piotr Golonka <piotr.golonka>
Component:	folders	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED UNMAINTAINED
Severity:	normal	CC:	bartoschek, kdenis
Priority:	NOR
Version:	4.7
Target Milestone:	---
Platform:	Fedora RPMs
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Piotr Golonka 2011-12-03 14:53:04 UTC

Version: 4.7 (using KDE 4.7.3)
OS: Linux

I recently moved to KDE-4.7, from previously used 4.5. What I hoped was that all the features of previously included (excellent!) KMail are also available in this new version... Apparently this is not the case:

The problem I want to report is that many operations that have previously been done by KMail itself, are now done with Akonadi, and since then we have no proper visual feedback of their progress.
For instance, when I command to move the folder to another folder (ie. right-click on a folder and select "move folder to"), the operation sometimes takes long (tens of seconds for large folders), and during that time there is no visual feedback that my command was accepted - the folder does not appear in the new place, the number of email messages in the "old" folder" do not change, no progress bar either...

This is very confusing.

So far, the only way I have found to trace that kmail/akonadi actually does someting was to start akonadi from a konsole (or, to be more precise, do "akonadictl restart"), and then watch the debug messages coming...

Reproducible: Always

Steps to Reproduce:
Try to move a folder, in particular if it contains ~1000 messages and a couple of tens of megabytes of data...
Try to move it from "KMail-Import" to "Local Folders", for instance. Or between the local storage and a IMAP resource

Actual Results:
No visual feedback!

Expected Results:
I'd expect to have the behaviour of kmail from before akonadi.
Namely:
* the progress bar (in the bottom-right of kmail) shows the progress of operation
* the folder pops up in the new place immediately, and while the messages are being moved you could see the message counter (in the folder list) being updated - you see that messages disappear from one place and appear in the other.
* the messages that have been moved to the new location, should be immediately available in the new folder: if I clicked on any of them, I could immediately read it.

OS: Linux (x86_64) release 3.1.2-1.fc16.x86_64
Compiler: gcc

Comment 1 Laurent Montel 2012-01-24 14:53:36 UTC

*** Bug 290136 has been marked as a duplicate of this bug. ***

Comment 2 Denis Kurz 2016-09-24 18:05:01 UTC

This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present?

If noone confirms this bug for a Framework-based version of kmail2 (version 5.0 or later, as part of KDE Applications 15.12 or later), it gets closed in about three months.

Comment 3 Piotr Golonka 2016-09-26 07:18:29 UTC

Again, as with 287514, I'm not able to confirm it.
In my recent attempts with kmail 5.3.0 (fedora 24), it took literally minutes to get the list of messages in the INBOX synced (and, indeed, progress bar was slowly progressing, yet I had not enough patience to wait for the list of messages to pop up)...
Hence, please, close this one too as "unconfirmed" or "not reproducible".

Being a KDE fan since versions 1.X, I'm looking forward to improvements to akonadi scalability/performance so that I could get back to use kmail again one day.

with very best regards,
 Piotr

Comment 4 Denis Kurz 2016-09-26 17:41:10 UTC

Piotr, sad to hear that you had to migrate away from KDE PIM. I'll keep your reports open till December as announced, just in case someone else is able to reproduce them for a recent version. Thanks for reporting back.

Comment 5 Denis Kurz 2017-01-07 23:48:34 UTC

Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.