Hi @nr458h @PackElend Sorry for the extremely late reply! Our uni announced online course and I was busy returning back home in China. In my previous description, I expect the following behavior:
Suppose we have the following tags:
- Joplin (top-level)
- Productivity/Joplin/User Guide
And we have notes A-D. I use the term
Productivity->Joplin to indicate this single tag named
Joplin in the database with its unique ID. I use the term
Productivity/Joplin to indicate the tag hierarchy on the UI level that the user will input/see.
Joplin to A will attach the top-level
Joplin label to A. Displayed as
Productivity/Joplin to B will attach
Productivity->Joplin to B (2 labels in total). Displayed as
Productivity/Joplin/Development to C will attach
Productivity ->Joplin->Development to C (3 labels in total). Displayed as
Productivity/Joplin/User Guide to D. Then search by
Productivity/Joplin. Will return B, C, D.
Productivity/Joplin to A afterwards will attach
Productivity->Joplin to A. Now A has 3 labels, displayed as
Productivity/Joplin from C removes both
P->Joplin->Development labels. Now C has only one label
This approach allows tags in different hierarchy to have the same name. And this differs from digiKam in the following aspects:
- In digiKam, after step 5, A’s tags are displayed as “Joplin”, “Productivity”. “Joplin”. This creates confusion.
- In digiKam, step 6 only removes “P->Joplin” but not “P->Joplin->Development”, which is kind of weird.
- Similar to 2, digiKam actually has a label management panel, where you can attach any single tag to the photo without attaching its ancestors, or remove any single tag without removing its decedents.
If I get it right, your idea says:
Attaching “Productivity/Joplin/Development” to C will attach only “Productivity->Joplin->Development” to C (1 label in total). Displayed as “Development”.
Following 1, to avoid confusion, we should not allow tags with the same name even though they are in different hierarchy. This makes sense though, because I read the source code afterwards, and notice that we have created an index on tag names in the current database.
Following 1, the parent tags are not attached. But if the tag panel looks like this
And the user clicks the orange area, intuitively the user will expect C to appear in the list. Hence the software should perform a recursive lookup to get the notes with child tags (e.g. P->J->Dev) of the selected tag (e.g. P->J).
Generalizing 3, when the user search by “Productivity/Joplin”, C should also appear in the search result to preserve consistency.
Since the names are unique, when the user search by “Development”, should C also appear in the result? There is a little confusing.
Following 3, it is invalid for the user to remove “Productivity/Joplin” from C. Also when the user removes “Productivity/Joplin/Development” (actually the user only need to input “remove ‘Development’” since name is unique), C will have no tag left.
Comparing to my previous idea, yours saves space in the database and UI, but requires the backend lib to do more. It also requires user to memorize his/her hierarchy design all the time because the UI lacks hints.
Sorry for writing so long, but I just come up with a merge of our ideas. It is almost based on yours except that:
Although storing only “P->J->Development” tag, on the UI it should display this tag as “Productivity/Joplin/Developemnt”.
In this way the user can use the same name in different hierarchy (say Joplin/Dev, Evernote/Dev). We should determine whether a tag already exists by two columns “name” and “parent ID”.
The user must input “Productivity/Joplin/Development” to remove the tag.
The user can search for C by “Productivity/Joplin” or “Productivity/Joplin/Development”. The user cannot search for C by “Development”.
Hope this is helpful, and please correct me if my understanding is wrong!