[Digikam-users] What is being/will be done about the tags management problem?

[Gilles Caulier]

2013/2/19 Jean-François Rabasse <jean-francois.rabasse at wanadoo.fr>

>
> On Tue, 19 Feb 2013, Gilles Caulier wrote:
>
>  Jean François,
>>
>> Please report this investigation in this bugzilla file :
>>
>> https://bugs.kde.org/show_bug.**cgi?id=268688<https://bugs.kde.org/show_bug.cgi?id=268688>
>>
>
> Gilles,
> it's not a bug. It's a *too* complicated problem with *too* many possible
> choices. And whatever fix is done, some users may agree
> and some other users disagree, depending on who does what.
>
> The actuel « merge tags » choice is a problem for reorganization
> but may be useful in some occasions : a user tags an image with
> Digikam and writes metadata to files. Then the image goes into
> LightRoom and the user adds other tags.
> Back to DK, re-read should, for this user, also merge the new
> lr:hierarchicalSubject.
> But this would be possible only if the DK tags are removed from the
> file metadata, if not DK will not even read LightRoom data.
> And it doesn't seem wise to provide also options to select in what
> order data should be read, the Metadata settings folder would no
> longer fit on a screen :-)
>
> That's why the problem is complicated. Providing all possible
> options and choices at application level would generate a monster.
> (In French a « usine à gaz » :-)
>

This will not be a "Usine à gaz" (GPL of course) if a clean metadata
control panel is done about this subject. I already talk about this topic
with Marcel in the pass. The goal is to check which option must be turned
on by default to satisfy a lots of users by default.

Secondary, the big question to know is how main Photo management program
work with tags workflow in metadata. When i said main applications, i said
real pro photograph application, as Aperture, NX, LR, etc...

And definitively, this cannot be an introduce small project for students,
but a real GoSC 2013 project, because it's more complex that i supposed in
my previous mail.

Gilles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20130219/1a13061d/attachment.html>