After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 509777 - Write parent tags to files
Write parent tags to files
Status: RESOLVED DUPLICATE of bug 345405
Product: f-spot
Classification: Other
Component: Metadata
SVN
Other All
: Normal enhancement
: ---
Assigned To: F-spot maintainers
F-spot maintainers
Depends on:
Blocks:
 
 
Reported: 2008-01-15 22:43 UTC by Ulf Rompe
Modified: 2008-01-16 07:48 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ulf Rompe 2008-01-15 22:43:36 UTC
All parents of the tags applied to a photo should be written to the file as well. At the moment only the applied tags are written.

Here's why:
Imagine a tag tree like this: Places->Czechia->Prague->Hotel_Ambassador
I take a picture of that hotel and tag it accordingly. Using the power of tag trees, everything that needs to be said about this picture is expressed by just applying the tag "Hotel_Ambassador". From now on, whenever I search for "Prague" in F-Spot, I get this picture. But outside of F-Spot, the only information left is the name of the hotel, leaving the audienve asking where in the world it might be.
Thus, if I tag a picture with "Hotel_Ambassador", I would want F-Spot to also write "Prague", "Czechia" and "Places" to the file.

My current workarounds:
Right now I use two methods to get every information into the files. For some subtrees I created tags containing redundant information in their names. The above example tree would read "Places->Places Czechia->Places Czechia Prague->Places Czechia Prague Hotel_Ambassador" using this technique. Because that's ugly, I am tagging other subtrees with every parent by hand, so that using the above example the photo would get the tags "Places", "Czechia", "Prague" and "Hotel_Ambassador". This method is visually more appealing, but it hides some error potential in case a tag is moved into another subtree and the additional tagging is time consuming.
Comment 1 Maxxer 2008-01-16 07:48:04 UTC

*** This bug has been marked as a duplicate of 345405 ***