View Single Post
Old 01-28-2011, 09:51 PM   #30
kiwidude
calibre/Sigil Developer
kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.
 
Posts: 4,223
Karma: 1333994
Join Date: Oct 2010
Location: London, UK
Device: Kindle Paperwhite 3G, iPad 3, iPad Air
Quote:
Originally Posted by Starson17 View Post
Yes, it's legacy. Kovid's original code was to match on identical titles only - without any regard to author...
Cool, hoped that was the case. As surely adding your exact match on author logic to trigger the user to decide what to do could esasily be merged into that. it is simple enough to test whether a book has an author to decide whether to match only on title or on title and author.
Quote:
I'm comfortable in the code for creating records, deleting records, grabbing incoming files and associated metadata, moving metadata around, searching the library for dupes, etc. but haven't had time to look very far into user interface construction. My skill stops at adding an option box and storing/retireving the option or adding a warning dialog and allowing that warning to be turned off.
Well maybe I can help with that - my Qt skills are still fairly newborn (or is that fairly stillborn?) but they have managed a little complexity with the configuration dialogs for Search the Internet for instance with grids, context menus, embedded widgets, signals etc.

There are two options to the GUI approach that I can think of. One is to modify the Calibre source code to reuse the library view. This would probably be the best long term option, but as it touches the very core of Calibre it would need pretty close Kovid supervision to gain any liklihood of patch acceptance if done by a Python muppet like myself.

Plan B would be to do it in a popup window as part of a GUI plugin. I reckon given enough time I could pretty much cope with writing that, though obviously you would be more "constrained" in functionality by not being on the official library view. The advantage is that you could happily add columns and right-clicks all related to just the task at hand (resolving duplicates) safely encapsulated within a plugin that Kovid doesn't have to worry about

The downside is that there are a number of things you take for granted in library view that would likely involve considerable duplication of code to offer. So it might start off pretty crude and basic. But IF the intent is just to list books that are duplicates, allow you to view formats and then merge the results it might be feasible?

I would presume you must already be doing what to me is the "hard part" of using the Calibre model/db to identify duplicates for a given book. So presumably rather than iterating over a collection of "adding" books you instead iterate over "all" books. Could be very slow, but I imagine you could do a few things like snapshot the results of the last time you "searched" and work with that until the user "refreshes" the duplicate search again. Again just thinking out loud before prematurely optimizing.

If I did all of that and it "worked" well enough, then the next step could be to "loosen the reigns" of that automerge option by adding the three sub-options I proposed and hence allowing the duplicate rows to be created when formats are duplicated.

Anyone have any thoughts on this? Bad idea/waste of time/etc?
kiwidude is offline   Reply With Quote