Bug 422087 - Move to different album does not move the original picture
Summary: Move to different album does not move the original picture
Status: RESOLVED NOT A BUG
Alias: None
Product: digikam
Classification: Applications
Component: Usability-Drag&Drop (other bugs)
Version First Reported In: 7.0.0
Platform: Microsoft Windows Microsoft Windows
: NOR minor
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-26 09:15 UTC by andrej.valencic
Modified: 2020-05-26 17:14 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In: 7.0.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description andrej.valencic 2020-05-26 09:15:52 UTC
SUMMARY
When using 'Move' (Drag&Drop or Left click) only the modified image is moved and not the original as well.

STEPS TO REPRODUCE
1. Do some editing on pictures
2. Move the selected images to another album
3. The original image is not moved


OBSERVED RESULT
After I did some editing on a lot of pictures I wanted to reorganize my albums and move images to different albums. What I found out is that with the "Move" operation only the modified versions (_V1, _V2) are moved, the original image is not moved along. Is this by design and for any particular reason? 

If I then copy the original images manually to the destination album/folder afterwards, DigiKam still seems to work as expected, for example I can still open the original in the Editor. I don't know what this kind of workaround means for the database itself - will this bring some problems in the future? 

EXPECTED RESULT
I would rather see that both the original and the modified version of the image are moved to the album I choose. This seems to me more appropriate as then I have all the pictures in the same album/folder. This helps me if I want to copy albums/folders to some other location/computer. 

SOFTWARE/OS VERSIONS
Windows: 10 64-bit, Build date: May 21 2020 (target: RelWithDebInfo)
KDE Plasma Version: 
KDE Frameworks Version: KDE Frameworks 5.70.0
Qt Version: Qt 5.14.2 (built against 5.14.2)

ADDITIONAL INFORMATION
Comment 1 Maik Qualmann 2020-05-26 10:51:21 UTC
I don't know if we really want that. It is not safe to resolve the associated image via the file name (_V1, _V2 etc.) We can resolve it via the database. But what if users want to save their original images to a folder other than the edited image? Only move the original image if it is in the same folder? But then I can hardly get the images separated.

We already have this function for sidecars, they move with the image. It is important and necessary for sidecars.

Maik
Comment 2 andrej.valencic 2020-05-26 11:12:35 UTC
Well, I agree there are many possible scenarios for users and it would be too complicated to cover them all. Anyway, this was more or less just a thought on the workflow that I use. I guess I'll have to adapt a little bit.

BTW, as you mentioned some users might want to keep originals in different folder than modified images, that was the thing that I liked in my Picasa days: edit an image and the original is automatically copied to .originals folder. That way it was dead simple to copy (only the edited) images to USB for example.  Again, my preference only.
Comment 3 andrej.valencic 2020-05-26 11:14:56 UTC
As a side note: up until now I didn't consider using sidecars, maybe I will look into it in near future.