A while back the excellent versioning feature was introduced in digikam. Unfortunately libkipi doesn't support it. This leads to problems when you try to export images or use the Batch Raw converter and the Batch Queue Manager. The tools either export the wrong images or are not able to create new versions of them. Reproducible: Always Steps to Reproduce: 1. activate versioning 2. use batch raw converter Actual Results: You either get new images instead of new versions or you can not specify which version you want to export to e.g. facebook. Expected Results: Batch Raw Converter and Batch Queue Manager should give the option to save a new Version instead of a new image. The export tools should allow to select which version of an image should be exported (either be able to generally mark a version of an image as primary version for viewing/export or always use the newest version)
This is a major feature request, and has been troubling me for some time. Versioning is currently implemented inside digikam. The parts required for this request are a) format XML describing the history and add it to the image's metadata on save b) for the parent object, define a history image id, write it to metadata if possible, and tell it to the host app. (there's some interoperability dirt here, unavoidable if the file is not writable) One approach to open this functionality to kipi plugins would be to add abstract methods to the kipi library. Problem: Only digikam will ever implement these methods. Advantage: Kipi plugins support versioning when run under digikam Disadvantage: Kipi plugins will not do this when run from all other host apps. The clean approach means factoring out a library from parts of digikam versioning code. Quite cleanly, the three files in libs/dimg/imagehistory have no dependencies except for Qt. To do this right, there is quite some glue code inside DImg, which can be factored out to the generic class VersionedImage without loss. It's depending on a bit of code in DImgLoader and DMetadata, mostly the way we create the file hash. All this essentially depends only on libkexiv2 and Qt and could be factored to a sublibrary of libkexiv2 (or a library of its own, unless we want to avoid that). This is not the full story, things like replaying actions and storing intermediate steps are probably out of the scope of opening to libkipi, at the moment. What we'd get here is the information: I am derived from file xy, with a step of the name yz.
As all batch tools into kipiplugins are now moved to digiKam BQM, this entry can be solved. There is no plan to add new tool to batch file locally which can require versioning support. Only too to export on Web service will be hosted in libkipi on the future. Libkipi features will be simplified in the future in this way. Gilles Caulier