Thanks for your thoughts.
Quote:
Originally Posted by Katja_hbg
Some months ago I adjust your "first book of a serie" so that it shows "the oldest (download date) unread book of each author". I assume with your new search I can do that as well.
|
Yes. Search for #read:no (or #unread:yes or whatever). Sort the book list by download date descending. Summarize by authors.
Quote:
|
About the second issue, if I understand that correct. This effect is also visible using this new search when you enter any other filter before. E.g. search "David". Search "summarize...". If so, that may confuse.
|
I'm not sure what you are saying. Filters before the summarize don't affect the book list so they won't have the same cumulative effect. Instead they affect the 'candidate' books that the summarize can show, still in the same order as the book list.
The easiest way to use it would be to use search to filter the book list then save that search as a temporary VL. This permits you to get back to the search result quickly. Next sort the book list in the order you want. Then summarize.
Finally, it is reasonable to summarize twice, that is summarize a summary, as I did in the example in the first post.
Quote:
Only as a quick idea: adding parameter-field for sort and sort-order.
Could that avoid the cumulative issue as you do not need "to look at the screen"?
|
It could, but it isn't practical. Sorts can be arbitrarily complex. We would need to create some way for the user to express multiple nested sorts on the search bar, which would be a bit wierd.
However, it might be possible to get the current sort and apply that before doing the summarize. This would eliminate the cumulative effect, with the downsides that
- performance would be worse. Perhaps much worse.
- it would no longer be possible to summarize a summarized list.
- it might end up more-or-less requiring using a temp VL (not clear about this).