SUMMARY STEPS TO REPRODUCE 1. assign a tag to a photo (do not hit "Apply") 2. move the photo to another folder 3. answer "Yes" when asked if you want to apply the changes OBSERVED RESULT DK leaves a .xmp file in the source folder, moves the photo to the destination folder, but does not apply the tag EXPECTED RESULT no .xmp file anywhere (my DK is not configured to do so), move the photo to the destination folder, and applies the tag SOFTWARE/OS VERSIONS Windows: 11 Home ADDITIONAL INFORMATION I set the component to "general" because I did not know which component I should set it to.
*** This bug has been marked as a duplicate of bug 204487 ***
If no "Apply" is performed and an image is moved, the loaded metadata is no longer consistent. In this case, we must discard all changes made. In all cases, an "Apply" must be performed beforehand; moving images at the same time does not correspond to the intended workflow. Maik
I understand your comment about the workflow and I agree that what I did was wrong. But: The current situation is misleading because DK behaves exactly as if it had applied the modifications, when it hasn't really done so. I feel that writing to the .xmp file doesn't count because most users don't check their folders frequently with a file manager, so that the user is left with the impression that everything went as intended and the .xmp file will never be seen (AFAIK DK doesn't use an isolated .xmp file, and it is probably best this way). IMO, it is a software's responsibility to prevent the user from doing things which can't be correct, or at least warn the user when something has gone wrong. So in this situation, I can see 4 different ways to improve things, if there are pending modifications, either: a. Disable moving images entirely. This solution works, but the user may not understand why moving is disabled. Don't forget that users aren't always quite dedicated to what they are doing so imagine doing a few edits, answering a phone call, and then returning to DK and go on with moving the images; the user could very well at that point forget about the pending edits and be puzzled by DK's silent refusal to move files. b. Upon moving, DK could display a message saying the move operation is impossible because there are pending modifications, and not perform the move operation. This is the solution which I would find best because the user knows what is wrong but hasn't lost his modifications (yet). c. When the move operation has been performed, display a message saying the modifications have been canceled because of the move. This solution is not as good as options a or b, because redoing the canceled edits can be tricky, but at least the user is warned. d. Apply the modifications automatically, which would not be a good idea IMO. It would break the workflow, and it would make the confirmation kind of useless.
Bug 204487 is definitely a duplicate, it doesn't matter if you change a tag or caption or anything else in the right sidebar. The problem is that the sidebar doesn't recognize drag and drop. It won't be easy to find a solution here. Maik
OK, I can imagine why it would be difficult. I haven't downloaded the source code and my tiny knowledge of c++ probably wouldn't allow me to understand much, so that I won't try to do more than "imagine". If I had tried to create something like DK, I guess I would have created an image to represent images. Images would have a flag saying that there is a pending edit (tag, caption...). When moving to a new folder (either by drag & drop or by cut & paste), I would check this flag and block the user if it is raised. But maybe this is impossible this way, maybe you can't block a drag & drop afterward. If this is so, I would simply disable drag & drop and cut & paste if the pending edits flag is raised. Again, this is pure speculation from me, maybe your object model is completely different, or maybe the way d&d and/or c&p work (especially across different OS) makes what I imagined impossible. Anyway, this is not something which should be solved ASAP. As you said, what I am doing does not conform to the workflow, and there is an obvious workaround: follow the workflow!
Sorry, in the second paragraph, I meant "I would have created an object to represent images".
"In all cases, an "Apply" must be performed beforehand; moving images at the same time does not correspond to the intended workflow." Whatever system ends up doing, it can't show different data at i) UI, ii) sidecar at old location, iii) sidecar at new location. Adding this possibility to workflow would make things easier for user (but I see you are unable to think usability at all) but minimum is that data is stored consistently wherever it's saved.
"The problem is that the sidebar doesn't recognize drag and drop. It won't be easy to find a solution here." Can system check the situation while updating database instead? It should be aware of file changing place and check sidecars from both old and new locations and update db properly and remove orphan.
... referring to https://bugs.kde.org/show_bug.cgi?id=492163
Could you do this? 1. File location is always saved to database. 2. Everytime file properties are updated, digikam checks where the file currently is, and does all needed to maintain database/sidecar integrity taking in account if file has been moved in the middle of action.
Git commit 5c63386b0148124b101f6b568e99a8f25376ea7d by Maik Qualmann. Committed on 27/08/2024 at 06:29. Pushed by mqualmann into branch 'master'. disable left sidebar if right sidebar modified Related: bug 204487, bug 492163 FIXED-IN: 8.5.0 M +3 -3 NEWS M +3 -0 core/app/views/stack/itemiconview.cpp M +1 -0 core/app/views/stack/itemiconview.h M +12 -0 core/app/views/stack/itemiconview_views.cpp M +7 -0 core/libs/properties/captions/itemdescedittab.cpp M +1 -0 core/libs/properties/captions/itemdescedittab.h M +3 -0 core/libs/properties/captions/itemdescedittab_p.cpp M +3 -0 core/libs/properties/itempropertiessidebardb.cpp M +1 -0 core/libs/properties/itempropertiessidebardb.h https://invent.kde.org/graphics/digikam/-/commit/5c63386b0148124b101f6b568e99a8f25376ea7d