View Single Post
Old 11-07-2012, 05:59 AM   #3
chaley
"chaley", not "charley"
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: 5,203
Karma: 821512
Join Date: Jan 2010
Location: France
Device: Many android devices
Quote:
Originally Posted by kovidgoyal View Post
2) Add some way for the device driver system to signal to the GUI that the book is not recognized by the device, the gui could then use an exclamation mark instead of a tick to indicate such problem books.
This is possible, but there are a few things to watch out for.

The in_library column, where the check marks are, is currently populated when doing book matching. This opens the question: what should happen if the book is both a problem book and in the library? We could:
- add two new icons, one meaning in_library & problem, and the other meaning not in_library and problem.
- add text to the field similar to what happens when DEBUG is turned on. In this case the field would contain text but might or might not contain a check.

Another question: how does someone search for these? Would we allow text searches on the nominally boolean column?

Third question: how does the column sort? Does the text change the nominal value so that they sort together?

None of these are really hard to deal with.

As for how to signal that a book has a problem, this can be done by agreeing on an attribute name for the property. This name would not be added to the list of standard metadata items, so it wouldn't end up in metadata.calibre or in OPF files. The sony driver does something like this for new books and ?_sort values to pass information to the collection builder. I suggest something like "_book_not_in_db" if we want a bool value, or "_device_book_problem" if we want a text value that will be displayed in the GUI. Because this value crosses from device land to gui land, we would want to document its existence in interface.py.

I can do the non-driver work. Probably not this week, but certainly by next week's calibre release. Let me know how you want to proceed.
chaley is offline   Reply With Quote