Version: 2.0.0 (using KDE 4.6.2) OS: Linux Some operations which are running in background do not give any visible feedback to the user and give a wrong impression about their state. Here just an example: Reproducible: Always Steps to Reproduce: * enter an existing album an select an image * copy the image (Ctrl-C) * create a new / empty album and enter it * paste the image (Ctrl-V) Actual Results: For several seconds nothing seems to happen: no progress bar, no hourglass cursor, just no visible reaction. You can use the program, navigate, or whatever - still having an empty album on the screen. Then if if you ask myself "did i really press Ctrl-V?" and press it again, digikam complains that the image already exists - while still showing an empty album. Expected Results: While things are running in background, the affected "target" should be locked (e.g. by setting the hourglass cursor on the target of a drag&drop or a paste operation) or maybe a "placeholder" should be put into the target view. This happened for other operations as well, e.g. when assigning names to several images (in context of face tagging, assigning in People/Unknown) - then the view and the model behind seem to get out of sync for quite a while and continuing to work can produce damage by applying operations to wrong items. The only kind of "feedback" I get comes from watching the CPU load in xosview... So for all album operations and all operations that affect multiple items, I can only do them by starting a task, wait for several seconds, watching the cpu load, and then continue with the next task. NOTE: This might also be related to some existing bugs, e.g. https://bugs.kde.org/show_bug.cgi?id=271473 https://bugs.kde.org/show_bug.cgi?id=267686
Do you see that entries 271473 and 267686 are closed ? Do you tried last digiKam 3.5.0 which include a progress manager on status bar to report all main operation state ? Gilles Caulier
Hello Gilles, I tried 3.5.0 and I must say that the progress bar really is a big improvement! Now it is up to the user to have some "discipline" and wait with further actions until all operations are finished. Another improvement would be to prevent images which are processed somewhere later, in some background operations, from being used in some other operations. For example: - create an empty album A - create an album B and fill it with ~500 images - select all of them - trigger some long operation, e.g. "rotate left" - drag&drop them into album A => some images remained in B, preview broken, duplicates are in A IMHO it could be a good idea to give all images that are queued for processing some kind of "blocked" state (like an "exclusive lock") to prevent things like these from happening...
All file move/copy operations progress must be reported to ProgressManager. This topic is already reported to bug #233063 All other point do not need progress indication. Gilles Caulier *** This bug has been marked as a duplicate of bug 233063 ***
Not reproducible with 7.0.0 beta 1.