Hierarchical tags/keywords: incoherent/unexpected behavior when applying first and second level keywords at the same time or not
Let's say I tag the Image 1 with the keyword Nature.
Then I tag the Image 2 with the keywords Nature|Flower.
Then I go back to Image 1 and I also tag it with keywords Nature|Flower
I will end up with the following tags in these images:
Before transitioning to darktable, I used other FOSS for photo management (mainly: digiKam, Shotwell), which would have lead to the following - more coherent/expected IMHO - results:
I think darktable should do as well.
This is not the same bug, but it is somewhat related to the same problem: https://redmine.darktable.org/issues/10447
#1 Updated by m laverdiere 9 months ago
I got some time to investigate more this issue and I now realize that issue 10447 is not relevant for what I'm trying to report here (speed reading may be hazardous!).
Now, things becomes more problematic since the release of version 2.4.3 yesterday, for which one of the advertised bugfixes (which look more like a regression to me...) is the following: "When collecting by tags, don't select subtags" (see: https://github.com/darktable-org/darktable/releases/tag/release-2.4.3).
What's that mean is that now, if I search in darktable with the tag "Nature" (alone), only the Image 1 will show up (unless you use a joker (%) in the search). IMHO, this is incoherent (and an unexpected behaviour), because if you take the proposed scenario in my main report, the only difference between Image 1 and Image 2 is the tagging sequence, not the user tagging intent. In this scenario, the user expected result is obviously that Image 1 and Image 2 should have the same tags and should be retrieved (collected) with the same tag query.
So, since version 2.4.3, it becomes more important that darktable has a coherent behaviour for hierarchical tags. It should still be possible to use a first-level tag (Nature) alone, but if a sub-level (Flower) tag is applied later, the result should not be different than what it is for an image directly tagged with first-level/sub-level (Nature|Flower)
Otherwise, with the current implementation, are we not loosing one of the great benefit of hierarchical tags?
#3 Updated by m laverdiere 2 days ago
According to the blog post related to new features in darktable 2.6 (see: https://www.darktable.org/2018/12/darktable-26/), the behavior for tag search is now the following:
The collect images in lighttable now has 3 modes to deal with hierarchical tags. When selecting a tag which isn’t a node leaf (i.e. a tag that has subtags), say, the “parent” tag:
A normal double-click selects only the images tagged with this particular tag. The search string is set to “parent”.
A control-double-click selects only the children, e.g. images tagged with “parent|child” but not “parent” only. The search string is set to “parent|%”, where “%” is a wildcard meaning “any string”.
A shift-double-click selects images tagged with the tag itself or any of its subtags. The search string is set to “parent%”.
While it might offer some more search flexibility/power, it does not answer the bug reported here.
The basic thing here is that we still need to have a consistent way to retrieve pictures/images with same tags, independently of the tagging sequence. Again, if Image 1 was first tagged Nature and after Nature|Flower (2 tagging steps), it should be retrieved the same way as an Image 2 that was directly tagged Nature|Flower (1 tagging step). Under the new search modes included in version 2.6, with "normal double-click" on tag "Nature" only the Image 1 would be retrieved, since Image 2 wouldn't have the standalone (without children) "Nature" tag.