[Digikam-devel] [Bug 142056] Save changes of image modifications with Versioning.

[Martin Rehn]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=142056         




------- Additional Comments From martinrehn hotpop com  2008-08-07 00:06 -------
Thanks for the summaries, Dotan! What remains to be figured out, as far as I can tell, is whether it is possible to come up with either a fixed naming scheme for the images, or some other way to locally store the version relationships such that other programs can interoperate with Digikam.

Using the F-Spot naming convention (but perhaps using png:s instead of jpeg:s) is one idea, but IIRC it would not in itself suffice to achieve interoperability with F-Spot, since that program uses its database to actually store the version relationships. Also, the F-Spot-style file names do not tell you which version of the file is the current one.

Perhaps it is not possible to do this? But it would indeed be nice if the Digikam albums were easily browseable with file managers, viewers and other photo managers, rather than the user having to employ an "export" feature each time she wants to get her pictures out of Digikam.

The idea would be that e.g. Gwenview, dolphinpart and KPhotoAlbum would have an option to show only the current version of an image, if that is available, and perhaps even to allow the user to switch versions of an image. Just to get started, here is a suggested naming scheme, based on Gilles' comment in #18:

Suggestion 1:
img1234.jpg <- original
img1234.current.png
img1234.mod1.png
img1234.mod2.png

Here, if I create a new version from "current", that would still be named current, but the old "current" would be renamed "mod3". It becomes slightly ugly if I then decide to revert to "mod1": "mod1" would then be renamed "current", and perhaps the old "current" would become "mod3" and there would be no "mod1" any more.

Suggestion 2:
As above, but "current" is a symlink to the current version, e.g. "mod2".

Avoids the above ugliness, but I hear there are platforms with no symlinks!?

Suggestion 3:
A local (hidden) text file specifies the version relationships.

Suggestion 4:
Give up making the version state locally interpretable; just store it in the database.

That last one is simpler, but it seems to really lock you in to using only Digikam. Anyway, this was just a first go at this.