Bug 272158

Summary: More user feedback about background operations
Product: [Applications] digikam Reporter: Thomas Eschenbacher <Thomas.Eschenbacher>
Component: ProgressManager-BatchAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: wishlist CC: caulier.gilles
Priority: NOR    
Version: 3.5.0   
Target Milestone: ---   
Platform: Gentoo Packages   
OS: Linux   
Latest Commit: Version Fixed In: 7.0.0
Sentry Crash Report:

Description Thomas Eschenbacher 2011-05-01 15:44:14 UTC 
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
Comment 1 caulier.gilles 2013-12-14 22:55:56 UTC 
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
Comment 2 Thomas Eschenbacher 2013-12-27 14:27:40 UTC 
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...
Comment 3 caulier.gilles 2014-08-30 08:11:40 UTC 
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 ***
Comment 4 caulier.gilles 2019-12-29 04:55:03 UTC 
Not reproducible with 7.0.0 beta 1.