[chaley]

Originally Posted by Starson17

I don't like real multiple libraries. Calibre already has support for multiple libraries via 3 methods - command line, Wizard and Preferences. I don't see that anything anyone else will write would interfere with your save search code.

The idea raised was to put saved searches (virtual libraries) on the library bar. I would rather not do this because libraries behave very differently from search subsets and the visual intermixing confuses the semantics. As for having multiple libraries, I could use them, but not enough at the moment for me to implement them.

Originally Posted by Starson17

I'd drop that idea and stick to the idea of storing search parameters, not search results.

and

Originally Posted by Starson17

Stick to saving search parameters, not results. Then these issues disappear.

and

Originally Posted by Starson17

This goes back to saving results, not search parameters. Is result saving required? Searches are really fast.

I fully agree with you. I confused things by mentioning playlists. I was not thinking of saving results, although that understanding is an obvious consequence of my choice of the word. What I was trying to nail down was 'subset of library' behavior; a relational projection/view if you will, similar to auto_playlists in MediaMonkey (and undoubtedly others).

I should point out that generation of search results will be 'search on demand', not 'search on metadata change', because that is how searches behave today. For example, if you search for books tagged X, then edit the metadata of one of the books found, that book will not disappear from the screen. In addition, newly added books appear, even if they do not match the search criteria. One must reapply the search to correct the results. This behavior makes using saved searches as virtual libraries a bit problematic, because what one sees may not be what the search would return. This behavior doesn't bother me (in fact I prefer it), but I can easily imagine contrary opinions.