[Bug 272158] New: wish: more user feedback about background operations

https://bugs.kde.org/show_bug.cgi?id=272158

           Summary: wish: more user feedback about background operations
           Product: digikam
           Version: 2.0.0
          Platform: Gentoo Packages
        OS/Version: Linux
            Status: NEW
          Severity: wishlist
          Priority: NOR
         Component: Usability
        AssignedTo: [hidden email]
        ReportedBy: [hidden email]


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

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=272158

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #1 from Gilles Caulier <[hidden email]> ---
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

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

https://bugs.kde.org/show_bug.cgi?id=272158

Thomas Eschenbacher <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|2.0.0                       |3.5.0

--- Comment #2 from Thomas Eschenbacher <[hidden email]> ---
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...

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=272158

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|wish: more user feedback    |More user feedback about
                   |about background operations |background operations
          Component|Usability                   |Progress Manager

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=272158

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CONFIRMED                   |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #3 from Gilles Caulier <[hidden email]> ---
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 ***

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel