Subtags not working as expected?

[TheChilliPL]

Having two tags, A (tag_id:1000) and B (tag_id:1001), with A having the subtag B¹, imagine you have files a and b with tags A and B selected respectively. If you look for tag_id:1000 or tag_id:1001, you only get one single file for each of them, despite the fact one of them should imply the other one. It makes the search function unusable

¹ Reading the documentation, I have a feeling subtag is a terrible name for that, as it's kinda the wrong way. “Sub-” implies part of, while it in fact specifies the tags the tag inherits its values from. Maybe it'd be better to name them “supertags” (super-, meaning above or over) or “parent tags”?

[Pheubel]

I agree that the naming can be easily confusing to new users, i fell for it myself. "parent tag" is in my opinion not a bad choice for it, but i would like to also throw in an alternative option with "implied tags". The advantage to it is that it clearly states that the tags attached to the current one will act as an umbrella tag that can be searched for instead. The downside to it is that it doesn't show hierarchical relation as well, and people my create a hierarchy loop a little bit easier.

[The-Stolas]

I had no problem with the search function of subtags once I understood that it is inverted, but the naming is kind of confusing. "Korra" needs to have a subtag of "Avatar", so when I search for Avatar I get everything and Korra and only Korra images if I search for her. It's a bit strange, because you would think Korra should be a subtag of "Avatar" (characater as a subtag of fandom), not the other way around. "Parent tag" is a more logical name in my opinion.

[CyanVoxel]

Subtags will be renamed to Parent Tags in future releases, this is a change I should've made earlier if I'm being honest.

As for the id search, I'm assuming you're using the "tag_id" search that you get by clicking on the tags themselves inside the preview panel or by right clicking and selecting "Search for Tag". This is working half as intended, and by that I mean that the ID search is a leftover developer test that will only ever return tags with that exact ID present on them (so no parent tags) - but this shouldn't be the option presented to users when they click "Search for Tag". I can work on a patch that will correct this behavior.

In the meantime, searching for the tag name itself will result in the correct behavior involving parent tags.

[TheChilliPL]

Subtags will be renamed to Parent Tags in future releases, this is a change I should've made earlier if I'm being honest.

As for the id search, I'm assuming you're using the "tag_id" search that you get by clicking on the tags themselves inside the preview panel or by right clicking and selecting "Search for Tag". This is working half as intended, and by that I mean that the ID search is a leftover developer test that will only ever return tags with that exact ID present on them (so no parent tags) - but this shouldn't be the option presented to users when they click "Search for Tag". I can work on a patch that will correct this behavior.

In the meantime, searching for the tag name itself will result in the correct behavior involving parent tags.

Yeah, I do. In the future, might be nice to implement finding tags by some specific text syntax (e.g. #tagname, although it gets slightly more complicated for tags with spaces). Also, I'm not sure if including the first parent tag in the parentheses is perfect. Surely might make sense sometimes, but often it might be arbitrary, and people could add it themselves to the tag name

[CyanVoxel]

Yeah, I do. In the future, might be nice to implement finding tags by some specific text syntax (e.g. #tagname, although it gets slightly more complicated for tags with spaces). Also, I'm not sure if including the first parent tag in the parentheses is perfect. Surely might make sense sometimes, but often it might be arbitrary, and people could add it themselves to the tag name

The search feature will be a lot more comprehensive down the line, with one planned change being to visualize tags differently from plain text in the search bar, like this for example: This will open up the door for easier ways to include/exclude tags in searches without having to worry about syntax limitations.

As for the first parent tag in parenthesis, my original intention was to only show this when you had two tags with the same name but different parents (ex. Shrek (Character) vs. Shrek (Movie) ), but in the meantime I've just kept this to always display. I agree that it may not always be necessary or desired, and even in the case of the original intention given above could leave out examples where you would want additional clarification. I was hoping to find a magic bullet solution that wouldn't involve just making the option a checkbox on each tag, but maybe it'll have to come to that. Any thoughts on that?

[TheChilliPL]

Personally I wouldn't mind having to manually name tags like Shrek (Character) and Shrek (Movie), to be honest, though including it automatically when there's name duplicates sounds good as well. How would that searching work with various tag categories, though? I see there's Tags, Meta tags and Content tags. While this distinction makes sense, wouldn't it be better to allow separate tag lists? (Or even allowing creating more of them; cause I think this distinction is hard-coded now)

[CyanVoxel]

Personally I wouldn't mind having to manually name tags like Shrek (Character) and Shrek (Movie), to be honest, though including it automatically when there's name duplicates sounds good as well. How would that searching work with various tag categories, though? I see there's Tags, Meta tags and Content tags. While this distinction makes sense, wouldn't it be better to allow separate tag lists? (Or even allowing creating more of them; cause I think this distinction is hard-coded now)

The Tags, Meta tags and Content tags distinctions are going to change as well in a future update (sorry for so much "in the future" stuff). The plan going forward is to replace the idea of "tag fields" with the ability to mark a tag as a "category" that the UI then treats differently, creating a similar organizational distinction but with much more customization and flexibility. It should also be a lot more straightforward to use than the current system of adding a tag field -> then adding a tag to that field.

So an example of how this would look with the built-in Favorite tag would be:

• "Favorite" inherits from a built-in "Meta" tag, which is toggled as a "Category"
• This then displays the word "Meta" as a section title, similar to how tag fields are currently displayed
• The "Favorite" tag would then automatically display underneath this "section", no user intervention required.

This means that:

• Users won't have to add tag fields before adding tags
• Users don't have to worry about adding the right tag to the right tag fields anymore, as it's all automatic
• These tag categories will be fully customizable by the user, including things like display color (and icons in the future 🤞)
• If a tag inherits from multiple categories, it will automatically be displayed under all of these categories when added without any further intervention from the user

[TheChilliPL]

Looking forward to all the changes. I've been waiting for such a piece of software for years, and seems it's already there. Just needs some more development 😉

[CyanVoxel]

Tag ID search issued fixed in #398