https://bugs.kde.org/show_bug.cgi?id=302527Drew N <
[hidden email]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |
[hidden email]
--- Comment #9 from Drew N <
[hidden email]> ---
Firstly, I see that there have been people other than myself complaining about
this as far back as January of 2012 if not earlier (
http://mail.kde.org/pipermail/digikam-users/2012-January/015725.html ). The
complaints are consistent and do not vary by platform / distribution. That
makes this a confirmed bug in a KDE member project and not the distribution
maintainers' problem. I for one have been annoyed by this on Slackware (which
doesn't mess with anything) as well as Fedora and Ubuntu (distributions that
are more opinionated).
Secondly, all of the proposed "fixes" and "work-arounds" I have seen don't
actually address the core problem: the template system is functioning on some
false assumptions. We should not be telling end-users that if they only do some
command-line voodoo then their problems will be solved. They'd not be using
Digikam if CLI voodoo was the most reasonable solution.
So, let's clear some things up about how users are clearly expressing that they
expect templates and Metadata Editing to behave.
(1) If there's not a value there in the template, but the original contains a
value in that field then users expect the two to be _MERGED_ and not that the
template set original fields to empty if not set in the template.
Unfortunately, this isn't always what happens—and when it is actually happening
sometimes it is hard to tell because of the way the UI is set up (it doesn't
warn the user when EXIF/IPTC/XMP fields contain different values, for
instance).
Ideally, fields in the template would be "multi-state" in nature—empty +
overwrite, filled-in + overwrite, filled-in + append (when supportable),
filled-in + "use as default if not set already", and empty + ignore / don't
clear. That can be boiled down to a few fairly simple epi-metadata properties
ideally in the form of an "always overwrite / merge (when possible) / don't
change existing value / use as default" selector per metadata field (presuming
that "use as default" only overwrites empty fields).
(2) Templates should act like templates. They are starting points, not the end
result. This is related to my first point and is the crux of the original
complaint in this bug report. In fact, both (while potentially separate work
items) should be fixed at the same time. If the "Caption / Tags" panel is going
to be read / write for some fields then it should be for all of them, even if a
template has already been applied. Conversely, perhaps the panel _should_ be
read-only and double-clicking on a field opens it in the "Edit All Metadata"
modal dialog.
Affected Versions: everything from the 0.x vintage through 3.5.0
Affected Distributions: All tested (including, but not limited to Debian,
Fedora, RHEL, Slackware, and Ubuntu)
--
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
