[Digikam-devel] How to apply changes in digikams IPTC settings to all tagged photos?

[Caulier Gilles]

Le Mardi 23 Janvier 2007 17:58, Marcel Wiesweg a écrit :
> > > So, this is not a "real synchronisation", because there still remain
> > > differences between database contents and metadata...
> >
> > The sync depend of Metadata settings from digiKam config pannel. This
> > problem can be a bug or uncomplete code in new MetadataHub class from
> > Marcel. Need to investiguate.
> >
> > > I think these are very complicated tasks, and this is why I still
> > > really, really think, that the "advanced metadata handling" should be
> > > swapped out completely from the sidebar options, so that they can be
> > > left simple and easy and usable by "everybody", while the complicated
> > > stuff will be in a independend tool. Then this tool can be developped
> > > further without changing the behaviour of digiKam itself. It would also
> > > make it much easier to achieve and maintain a consistent behaviour
> > > thruout the sidebars because added functionalities in the "advanced
> > > tool" don't have to be in the sidebars too and they can be left
> > > untouched even if fantastic new options are added to the "advanced
> > > tools" in future.
> > >
> > > - - - - - - -
> > >
> > > For the sync tool, I would suggest some options that the user can
> > > choose from before starting it:
> > >
> > > - overwrite Metadata with the values, that are set in digiKam settings
> > > (like Copyright etc.)
> > > - OR leave these Metadata unchanged
> > >
> > > - overwrite keywords in Metadata with tags from database (which also
> > > means, keywords will be removed/overwritten with empty space when there
> > > are no tags) -- OR add tags to existing keywords (as it does now)
> > >
> > > Then, when choosing "overwrite mode" for both options there will be a
> > > complete, real synchronisation between database and metadata. On the
> > > other hand the user can decide to leave some inconsistency if this
> > > better suits his/her needs.
> >
> > Hum, Marcel give me your viewpoint... Personally, I prefer a simple tool
> > where picture metadata are exactly the same than DB content, following
> > setup of course.
>
> See my other mail
>
> > > - eventually: only to selected images
> >
> > yes. the code is ready to be used.
> >
> > Marcel, you just need to call the new class :
> >
> > BatchSyncMetadata(QWidget* parent, const ImageInfoList& list)
> >
> > ... with the current selected images list from album, and the dialog will
> > appear. I think than this dialog is mandatory if more than one image is
> > selected to be synced because it can take a while. Without the dialog,
> > the user don't have any progress feedback...
>
> Yes I will add that if more than one, two?, five? images are selected

Well, if you only show the progress dialog if you have more than 10 pictures 
selected (for example) and you don't show it with 9 pictures, the users will 
be confused... and certainly an Usability report will do in B.K.O. I 
recommend you to :

- not show the dialog if one image is selected.
- show the dialog if more than one image is selected.

... and we will see the users feedback after beta1.

>
> > > - - - - - - -
> > >
> > > during these tests I also (re-)found some other stuff, don't know if
> > > already mentioned in bugs/wishes:
> > >
> > > - when a file is copied into an album folder and that file contains
> > > Metadata keywords that do not exist as tags yet, then digiKam creates
> > > tags for these keywords, but the tags are not checked
>
> Confirmed, I need to investigate
>
> > > - if you then check those tags, the keywords get duplicated
> > > (this also happens with the new sync tool, because it adds tags to the
> > > Metadata even if they same tags already exist as keywords - could be
> > > solved with the "overwrite"-option suggested above)
> >
> > For these one, this can be a bug in KIO-Slave. Right Marcel ?
>
> The duplicate keywords:
> For DMetadata::setImageKeywords, all tags contained in newKeywords should
> probably be included in oldKeywords as well, so that they are removed
> first, and there are no duplicates?
> One line of code, but where, in DMetadata or in the code that calls
> DMetadata::setImageKeywords?

everywhere. Use grep to find each occurence, or Find in File with KDevelop.

Also there is a non-solved problem in all drag & drop stuff with don't use 
MetadataHub class. Your new class must be used instead to call directly 
DMetadata class. Like this all will be homogenous.

Other important task TODO :

Also, when kipi-plugins 0.1.3 will be released, a new common implementation 
shared between kipi-plugins and digiKam must be done about the Exiv2 
interface.

A new libkexiv2 library must be done, merging kipi-plugins/Exiv2Iface and 
digiKam/DMetadata.

In fact:

- In kipi-plugins, the Exiv2Iface must be remplaced by the new shared library.

- In digiKam, DMetadata must be derived of libkexiv2. Some usual methods of 
DMetadata (dupplicated in kipi-plugins/Exiv2Iface) will be provided by 
libkexiv2. All others methods, more dedicaced to digiKam core must be 
implemented to DMetadata.

The question is : digiKam 0.9.1 must be depand of future libkexiv2 ? I think 
no. We release 0.9.1 and after we change the DMetadata class...

Fine for you ?