Enhancement Request: Option to quickly select filtered tag browser categories

Bug #1989813 reported by ownedbycats
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
calibre
Fix Released
Undecided
Charles Haley

Bug Description

See this post: https://www.mobileread.com/forums/showthread.php?t=349100

One idea I've thought of is a button/option that would select all filtered tag browser items in one click and restrict the book list. I've also had situations where this could be useful.

Thank you!

description: updated
Revision history for this message
Charles Haley (cbhaley) wrote :

@kovid: FWIW: I can't think of a straight forward way to do this. It isn't hard to produce a list of (category, value) pairs from the filtered tag browser. This can be converted to a set of book ids. However, getting that set into the search mechanism is a mystery. Building a search string is out because the set can contain may thousands of ids. Building a search string from the pairs is possible and would probably produce a reasonably-sized search string, but performance will truly be terrible.

One approach I have thought of that is performant would be to create a new search term, for example 'in_tag_browser'. The tag browser would pass the set of filtered book ids to db.cache. A search like "in_tag_browser:true" would check that the book id is in the current filtered set.

Another option is to filter in view.py.refresh(), ensuring that _map_filtered is restricted to ids in the list. In this case the tag browser would pass the list to view (db.data.set_tag_browser_books() or some such). Using this method the restriction would be recomputed on every tag_browser.refresh() and would be used whenever the GUI does a refresh. I prefer this approach because a) it doesn't change the name space, and b) operates only on the GUI booklist / cover browser.

Neither of these approaches answers the UI question "how does ask for this behavior"? A checkbox could be added to Prefs/Look & feel/Tag browser, but that might be too hard to use if what one wants is a toggle. Adding another button to the search bar seems overkill. It could be added to the TB context menu.

What do you think?

Revision history for this message
Charles Haley (cbhaley) wrote :

Actually, using the existing VirtualFields mechanism works. This approach doesn't require a UI. The user can build a VL with the search or add that search as an additional search in the VL menu.

That leaves 2 questions:
1) Should it be done at all?
2) What is the key string? in_tag_browser?

Revision history for this message
Kovid Goyal (kovid) wrote :

1) I dont have a strong opinion on whether it should be done or not. If it is done though I will insist on make it at least a little discoverable/useable. Maybe a tag browser config setting to have it filter the book list automatically. Or a button in the tag browser find box. Or something.

2) in_tag_browser should be fine

Although thinking about this, why not make this completely independent of the Tag browser. Create a new search prefix "in_category:" that will search for all books that are in a category that matches the search expression. Once that is done, the Tag browser can use it to auto filter the book list if desired.

Revision history for this message
Charles Haley (cbhaley) wrote :

The independent solution doesn't solve the problem. It needs to know what categories are displayed in the tag browser to restrict the categories to examine. This doesn't negate the idea of adding "in_category", which would a form of the existing "all" that ignores the limit settable in Prefs / Searching.

I will look more at in_tag_browser and its discovery.

Revision history for this message
Charles Haley (cbhaley) wrote :

Done using a new Virtual Field, in_tag_browser that is searchable using 'in_tag_browser:true' (or false or ...).

The feature is discoverable through a new menu item in Configure tag browser: Filter book lists. This menu item can be 'clicked' using a shortcut key.

Changed in calibre:
assignee: nobody → Charles Haley (cbhaley)
status: New → Fix Committed
Revision history for this message
ownedbycats (ownedbycats) wrote :

Should this be marked as "fix released" by now?

Kovid Goyal (kovid)
Changed in calibre:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.