View Single Post
Old 03-19-2024, 10:01 AM   #7
chaley
Grand Sorcerer
chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.
 
Posts: 12,456
Karma: 8012886
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
Quote:
Originally Posted by kovidgoyal View Post
The rest of calibre would still be available. You could pre-apply any VL or have a button to apply a new one. The popup would function like the existing browse notes or browse annotations popups that are maeant to be used alongside the main calibre window. The main con is its a lot more work to implement. But usage wise it would probably be easier to use.
One possibility within the amount of time I am willing to put into this would be a dialog where the user would construct the query. The dialog would have a "Show" button (or some such) that would update the book list with the results of the query. Each operation would have its own line in the dialog. The dialog would non-modal. The gui would refresh when the dialog is closed.

There would be 2 query operators:
  • search: a standard calibre search expression
  • filter: reduce the result to the first value(s) in some field. Parameters: field name, acceptable count, and sort order (asc, desc, not changed).
For example, this query expression:
  • search: series:true and #read:no
  • filter: series, 1, ascending
  • press "Show"
would show unread books with the lowest series index.

One possible modification is not to put the "sort" in the filter but instead to have a separate sort operator. In this case the expression would be
  • search: series:true and #read:no
  • sort: series, ascending
  • filter: series, 1
  • press "Show"
The query for unread books with the highest series index would be
  • search: series:true and #read:no
  • sort: series, descending
  • filter: series, 1
  • press "Show"

We would probably want to be able to save & load querys.

It isn't clear to me that something like this is easier to use then embedding the filtering into the standard search expression. It does have the advantage that all the steps are explicit and allows the sort to change in the middle of the query. That in itself might make it (or something like it) preferable to embedding the filtering.
chaley is offline   Reply With Quote