Merge stuff in user categories with same name.

[silentguy]

In light of the new grouped search user categories and hierarchical tag browser, I was looking into merging stuff in the Tag browser.
e.g. I have a combined search for "series,#series2,tags" and items with the tag "Star Trek.DS9", the series "Star Trek.DS9.Relaunch [8]" and the #series2 "Star Trek.DS9.Mission Gamma [1]". This currently leades to three "Star Trek" in the tag browser, and each one will search it's origin category.

My first thought was to start with modifying the search generated in tag_view - tokens to just search the grouped search if possible and then as a second step try to figure out how to merge the entries in the tag browser. I Expected the first one to be easy as the tooltip of the items already displays the proper user category, but it turned out more difficult then I thought. Am I seeing this right that he just reuses the same object in the user category and in the actual category?

So I guess I would have to clone/recreate the object while merging them. Seems more difficult then I thought. Could someone give me some pointers where the user category tree is actually build?

Or am I trying something that will turn our really really complex? Now that I think about it, it might break some stuff that I never use. e.g. drag-n-drop on a merged entry would not be defined. Darn, it sounded to easy in my head.

[chaley]

You are correct, wherever possible, calibre uses the same 'Tag' object when placing the same tag in the TreeView. This permits several things, the most important being sharing of search state.

My understanding is that you want the item in the global-search-term (GST) user category not to be an instance of the tag, but instead be an instance of something like a search term. Although I wouldn't want it to behave this way, I can see why you would.

There are two ways to accomplish this.

1) The best would be two build the category information the way you want. The list of tags used in a category is built in library.database2.get_categories. There is a block of code there that constructs a temporary user category by merging all items from the 'real' categories into the new category. The block of code after that builds the category tag structures for all user categories, including this temporary one. You would change that code to:

• Build a set of tag names. Because it is a set, duplicate names will be merged. You will need to decide what to do about case.
• Build a list of new Tag objects for these items, setting the category_key to @GST_name. What you will do about item counts and the like is a mystery.
• Sort the entries. It makes no sense to sort by rating or count (both are zero), so use alpha
• Add the list to the categories that get_categories will return
• Make the changes in tag_view to handle these new Tags. At minimum you will need to change TagTreeItem to handle the decoration icons, and tokens() to handle clicked searches.

2) Rewrite the search category when the search is emitted. This way would leave the duplicates in the list, but would emit @GST_Name:val instead of the original_category_name:val. To do this, you:

• Change TagsModel.__init__ to make a copy of the Tag nodes in a GST user category so that clicking on a tag isn't shared with other categories.
• Change tokens() to check if the node being processed is a global search term node (node.is_gst is True). If so, then use that category name instead of tag.category in the rest of tokens()

Neither way is particularly difficult. That said, I am sure that there are corner cases with both of them.