[Digikam-users] Suggestion for a Showfoto

Thomas Sperre thomas.sperre at yahoo.com
Thu Apr 10 04:46:08 BST 2008


I take it that showfoto is the image editor part of digikam? I am using 
kubuntu 7.10 and the kubuntu default shipped digikam version 0.9.2 (KDE3.5.8) 
and in that version the image editor has no name, just "image editor".

The changes suggested are good imho. I don't like "modal dialogs" if that 
means dialogs that work to the exclusion of all other functionality in the 
program.

I'd like to comment on two things though:
1) workflow
2) data storage

1) I am not sure if Risto was aware of it, but many applications 
use "workflow" as a synonmymous term with macro: a collection of discrete 
steps to be performed in a given order in the editing of data using various 
functionality available in the program (and/or external applications). 
A "script" (although usually edited with tools in the programs GUI) which can 
be stored, and applied to more than one instance of data (in this case 
images). This is nice to have, especially for bulk data handling. 

Workflows could be used for automating series of actions that are always 
performed similarly and considered routine boring work for the user. One 
example of a series of actions I could like to have put into a "workflow 
object "that I use every time I am "done, for now" editing a picture: 

*save file regularly (see remarks under 2) below)
*save copy to screen size resolution and put in wallpaper slideshow folder
*export copy to flickr using specified settings 
*print copy on my printer in selected reolutions and picture size etc
*send e-mail to "recipient" "look at my new cool pictures" "+link to image in 
flickr"

2) In my opinion, a more user-friendly data handling is possible in showfoto.
When a picture is selected for editing, the original should rest un-changed, 
with original filename on disk. (I assume this is started from digikam 
although I think showfoto can work standalone too?)
 
The editing should work on a copy. When the user selects save, the default 
option is to save the copy along with the original image. Alternative to 
overwrite original image should be available and in application settings it 
should be possible to reconfigure the default. 

When the user continues to edit the picture, and then later selects save 
again, default should be to save yet another file, and keep both the 
original, the first edited version and the new edited version. Alternative: 
overwrite first edited version, overwrite original (and destroy all other 
versions.) And so forth for the third edited version. Of course, it is 
possible to create multiple new edited versions based on the first edited 
version - and then you have a tree with several branches. 

I realize I am describing a version-handling like system for storing images as 
they are being edited. I am quite sure it must be possible to implement that 
but not skilled to do it myself, so I thought I should challenge someone else 
to implement it. :-) 
 
PS: some kind of storage space limit per tree created (per edited picture) 
might be a good idea even if storage is cheap these days. For laptop users it 
is more restrictive than for the typical desktop user, who is rapidly 
approaching terabytes of storage space if he/she is an enthousiast. 

-- 
Thomas






More information about the Digikam-users mailing list