*** *** SUMMARY It seems that for files in an album, a drag/move out of the album to an external target (i.e. desktop) physically moves the file, but the album does not handle the delete process gracefully. STEPS TO REPRODUCE 1. Select a file (I am using files in the root album) 2. Right-click and drag the thumbnail out of the environment (i.e. to the desktop or a folder on the desktop etc) 3. Select Move as the drag operation requested. OBSERVED RESULT Image is physically moved, but Digikam does not update the view/album, such that the thumbnail remains. It will allow a double-click (with a black image shown, not a file-not-found error). Only an F5 refresh will remove it, and that reindexes the view to the top of the album EXPECTED RESULT As with internal moves between albums/folders, or moves from an external source to a Digikam album, a move out of the system should update the view and the thumbnail database. The view position should be persisted, as with internal moves, so that this process is transparent to the workflow. SOFTWARE/OS VERSIONS Windows: macOS: (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
The problem is known and has already been reported. I'll see if I can find the duplicate. The problem is that we don't get any feedback when using external drag and drop. This is because the external program does the cutting/moving. You could just activate album monitoring in the digiKam settings if you absolutely need it. Maik