https://bugs.kde.org/show_bug.cgi?id=142056Dotan Cohen <
[hidden email]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |
[hidden email]
--- Comment #38 from Dotan Cohen <kde-3 dotancohen com> 2009-06-07 20:07:49 ---
> The comments above are heavy on naming conventions but light
> on use cases.
Probably because the devs need to decide on a nameing convention to code!
>The only use case is the very linear:
I have other use cases, but let's examine this one.
> user edits an image a few times and each version (a saved edit) is
> preserved in a separate file; only one version of an image is
> displayed. This struck me as being not particularly useful for my only
> typical use cases
It is useful for our family use case. We are now organizing partially with
F-Spot, for the photos that we edit. This is quite what we do. It's fun to see
which family member can improve a particular photo in the best way! And who
forgets to remove the obvious redeye!
> If I change a file, I don't edit, save new version, edit new version,
> save newer version, edit newer version, etc. until I have a the single
> image that I'm after.
But some families do. Our does, although each edit usually starts off original
from the original image.
> That really does not work well for JPEG images, where each save is going
> to degrade the quality.
That is why Gilles declared that png is better, and png seems to be the most
likely candidate, not jpg.
> More typically, I am not aiming for a single "current" version of
> a file.
It's hard to say how typical your use case is. Shall I pester the F-Spot list
for users who actually use this feature? I think that they'd gladly help.
> If this feature is added, I would rather it not get in the way of the
> more complicated version control that I usually do manually. Of course,
> I'll have to remember not to use a convention that accidentally coincides
> with the convention proposed in this "bug" or I'll get screwed when I take
> on a new digiKam.
This is a very good, important point. Gilles, can the mod filename be
configurable in the options? That should make everybody happy, even those who
want F-Spot compatibility (assuming that the database issues can be worked
out).
>Linear version tracking is a nice feature for those who are just fixing
> an image and emailing it on (assuming they are not concerned about JPEG
> losses as each version is created). Aside from that, it is not very useful
> unless it can track a "tree" of image versions and allow several nodes in
> the tree to be visible "current" images.
Although our usage method is in fact a tree (several different mods all
starting from the original image), there are few enough nodes that storing them
in a linear fashion is acceptable.
--
Configure bugmail:
https://bugs.kde.org/userprefs.cgi?tab=email------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Locked
