Version: (using KDE 4.2.2) OS: Linux Installed from: Fedora RPMs I selected 2000 images, then applied a tag. I then could do nothing else while digikam updated the images. Expected behaviour: Image metadata is handled by a background process, and the program remains ready to serve user. Implementing ideas: * Database is updated immediately. Database has flags indicating that images are not in sync. * Changes in metadata are also written to a journal file. * Updater program is started. It starts reading journal entries, writing them to the files, and clearing the journal entries. If updater runs as a separate process then it can finish after digikam closes. For the duration of the updater process, the affected pictures are flagged as not being in sync. If user edits a picture, then updater skips the data for that pic, coming back later. If program halts, then journal is left un-run. Updater is started on next start of digikam. Would this work?
I have been thinking to moving this process out of the main thread as well, but going for an easier approach. Digikam can just do this in a separate thread and almost refuse to close if it is still working when the user closes it. Putting flags in the database is a solution that requires a lot of work and overhead.
Progress update: For all such actions originated from the main icon view, a thread is used. Sidebars still use the old method and will do this probably until they are ported to model/view (post 1.0). Check at shutdown is TODO.
Marcel, What's new about this file ? Gilles Caulier
*** Bug 266684 has been marked as a duplicate of this bug. ***
Marcel, with all improvements done with ProgressManager and Maintenance tool, this report can be considerate as solved, i think... Sherwood, Do you tried to use last digiKam 3.5.0 ? Gilles Caulier
Maintenance tool as since a while a Matadata Synchronizer which can be used in background an support multithreading and multicore CPU with a feedback given through Progress Manager. Gilles Caulier