[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