Bug 204487

Summary: HUB : caption not saved when moving images after entering caption
Product: [Applications] digikam Reporter: Simon <simon.eu>
Component: Metadata-HubAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles, davito9w, marcel.wiesweg, marcela.maslanova, myaccount132
Priority: NOR    
Version: 3.5.0   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In: 8.5.0
Sentry Crash Report:

Description Simon 2009-08-20 09:54:59 UTC
Version:           1.0.0-beta4 (rev.: 1013480) (using 4.3.00 (KDE 4.3.0), Debian packages)
Compiler:          cc
OS:                Linux (i686) release 2.6.30-5.slh.1-sidux-686

Reproduce:
* Select some images 
* Enter a caption. Do _not_ unselect the images.
* Drag and drop the images into a new folder.
* Open the new folder
The caption won't be there anymore.
Comment 1 caulier.gilles 2009-08-20 09:57:44 UTC
Agree, just tested...

Gilles Caulier
Comment 2 Simon 2009-12-28 17:09:48 UTC
Will this eventually be fixed? Would be nice. It's a nuisance having to unselect the images to make digikam writing the changes to the images, selecting all of them again and _then_ moving it to another directory.
Comment 3 Marcel Wiesweg 2009-12-29 14:46:39 UTC
The easy workaround is to press "Apply".

It should eventually be fixed, but it's not easy - the view doesn't know what happens to any drag operation started.
Comment 4 caulier.gilles 2011-03-11 11:24:39 UTC
This entry still valid ?

Gilles Caulier
Comment 5 Simon 2011-03-12 16:52:19 UTC
a) I select the images, enter a caption, and move them to a different directory. Digikam asks: Apply changes? I say yes, yet nothing is applied.
b) Same, but with «Don't ask» enabled. Same result.
Comment 6 marcela maslanova 2011-07-21 20:46:18 UTC
I have 1.9.0 and it seems to behave differently. I copied files from one directory to another and caption stayed with question Move or Copy.
Comment 7 caulier.gilles 2011-12-14 09:17:59 UTC
Simon,

This file still valid using digiKam 2.4 ?

Gilles Caulier
Comment 8 Simon 2011-12-14 09:19:55 UTC
I'm still on 1.9 here on Debian sid, with broken Marble ...
Comment 9 Simon 2012-08-08 14:42:14 UTC
PS: Still there after 3 years in 2.6.0.
Comment 10 caulier.gilles 2012-08-08 16:52:12 UTC
Simon,

Just for testing, to see if it's a problem in your DB file, If you create a new user account on you computer, and you run digiKam 2.6.0 from scratch with few image in collection, can you reproduce the problem ?

Gilles Caulier
Comment 11 Simon 2012-08-08 19:32:18 UTC
I have re-installed the whole system several times since, on multiple computers, this one has a plain new DB (created with 2.6.0) and not one updated from 1.0.0 ;)

Simon
Comment 12 caulier.gilles 2013-11-25 17:13:57 UTC
Simon,

What's news about this file using digiKam 3.5.0 ?

Gilles Caulier
Comment 13 Simon 2014-04-05 06:19:59 UTC
Still present in 3.5.0.
Comment 14 caulier.gilles 2014-08-31 22:15:09 UTC
Simon,

Last digiKam 4.2.0 is out with a lots of improvements done everywhere. Problem still reproducible ?

Gilles Caulier
Comment 15 caulier.gilles 2016-07-16 13:24:30 UTC
Simon,

What's news about this file using digiKam 5.0.0 ?

Gilles Caulier
Comment 16 caulier.gilles 2016-12-01 13:47:41 UTC
Can you reproduce the problem using digiKam Linux AppImage bundle ? The last
bundle is available at this url:

https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM

Gilles Caulier
Comment 17 caulier.gilles 2020-08-03 05:00:11 UTC
digiKam 7.0.0 stable release is now published:

https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/

We need a fresh feedback on this file using this version.

Best Regards

Gilles Caulier
Comment 18 caulier.gilles 2023-04-20 05:54:58 UTC
Maik,

What do you think about this old report. Work around is to press Apply in this workflow, as Marcel comment #3.

Gilles
Comment 19 Maik Qualmann 2024-08-16 09:27:53 UTC
*** Bug 491778 has been marked as a duplicate of this bug. ***
Comment 20 Maik Qualmann 2024-08-16 14:24:17 UTC
*** Bug 491778 has been marked as a duplicate of this bug. ***
Comment 21 Maik Qualmann 2024-08-25 14:00:44 UTC
*** Bug 492163 has been marked as a duplicate of this bug. ***
Comment 22 2024-08-25 14:32:58 UTC
Ability to move files directly to new location considerably saves time when handling many pictures as writing occurs during move process and doesn't have to be waited to finish while handling next bunch of pictures. While digikam has lots of features, they generally lack usability and having this possibility improves it. 

At 8.4.0 UI shows updated tags at new location but there's sidecars at two locations with including differing data which potentially later corrupt data.
Comment 23 Maik Qualmann 2024-08-27 06:30:34 UTC
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 491778, 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