[Digikam-devel] [Bug 303690] hierarchical tags inconsistencies

[Marcel Wiesweg]

https://bugs.kde.org/show_bug.cgi?id=303690

Marcel Wiesweg <marcel.wiesweg at gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #1 from Marcel Wiesweg <marcel.wiesweg at gmx.de> ---

> 1. the "assign tag"/"remove tag" menu (after right clicking an image) shows
> the full path of a subtag 

Yes it does

> 2. In the properties view under "digikam properties" I find:
>    Tags: People / George, Maria
>     suggesting that Maria is no more a subtag of People

No, it shows:
People / George
 Maria

which is quite different. We could think about using "-" as the list character;
we chose " " at the time to limit visual clutter.

> 3. in the database (sqlite in this case) only the child tags are stored
> (this can be fine)

Yes it is

> 4. in the XMP section of the metadata view the full hierarchy is saved in
> various keys of various namespaces e.g. "Xmp.digiKam.TagsList"

Yes it is

> 5. filtering for people in the left tag view returns all photos having
> either the people parent tag or *just* any of the subtags

This depends on your including subalbums or not

> 6. filtering for people in the right tags filter view only returns images
> explicitly tagged with the parent tag people but *no* photos only tagged
> with the subtag.

Yes, it does. Same behavior as above. There's auto-toggling children here now,
there's I believe indeed no include-subalbums. Precise filtering must be
possible.

If a parent tag is assigned or not is a matter of taste. Personally, I often
assigned up to three tags in the hierarchy when describing places; others may
only assign the very child tag. In the contexts of people, I assign only the
very child tag (the person) and never any parent tag (the group). Much more
contexts can be imagined, we cannot impose interpretations.

-- 
You are receiving this mail because:
You are the assignee for the bug.