Register Guidelines E-Books Search Today's Posts Mark Forums Read

Go Back   MobileRead Forums > E-Book Software > Calibre > Development

Notices

Reply
 
Thread Tools Search this Thread
Old 04-14-2011, 03:40 PM   #46
Starson17
Wizard
Starson17 can program the VCR without an owner's manual.Starson17 can program the VCR without an owner's manual.Starson17 can program the VCR without an owner's manual.Starson17 can program the VCR without an owner's manual.Starson17 can program the VCR without an owner's manual.Starson17 can program the VCR without an owner's manual.Starson17 can program the VCR without an owner's manual.Starson17 can program the VCR without an owner's manual.Starson17 can program the VCR without an owner's manual.Starson17 can program the VCR without an owner's manual.Starson17 can program the VCR without an owner's manual.
 
Posts: 4,004
Karma: 177841
Join Date: Dec 2009
Device: WinMo: IPAQ; Android: HTC HD2, Archos 7o; Java:Gravity T
Quote:
Originally Posted by kiwidude View Post
@Starson - yeah I did warn about the config file thing in the post it is attached to, but can't blame you for not reading all of my ramblings
I read it. The embarrassment is that I didn't remember it, until it croaked on me.
Starson17 is offline   Reply With Quote
Old 04-15-2011, 03:46 AM   #47
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: 11,703
Karma: 6658935
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
Quote:
Originally Posted by kiwidude View Post
  1. Drop the "Show all duplicates" menu option and make this the default behaviour, or...
  2. To (just) have a persisted option on the search dialog, so the user can choose whether to display all the results as a group or to review individually, or...
  3. To have it both on the dialog, and have the "Show all duplicates" menu option which act as a toggle to turn the behaviour on and off on the fly.
The menu option could come in handy because of the issues with showing duplicate exemptions discussed below, although we could just treat "next result" as a similar trigger to turn the GUI "back into" the show all duplicates mode. Thoughts?
I would be happy with any of these. That said, I think that #2 is the best way forward, because of situation and workflow differences. My guess is that restriction+marking is best when working with a fairly clean library where the number of cases is small (probably what all of us have), vs a mess where there are 100s of duplicates. In the latter case, the user might prefer to deal with them group by group.
Quote:
That is a tough one if part of the issue is stuff like "A" and "The" prefixes being part of the reason for a title being a duplicate in the first place . There is a step in the process before I allocate the group numbers where I can sort them however I like - so what I have done just now is to sort by their fuzzy key. You would still get some "quirks", but as a general flow there would be some consistency at least.
Sorting by fuzzy key is probably better than what I had in mind -- sorting by title_sort.
Quote:
When displayed, what I am doing (now) is to first sort by title, and then by marked group (which is why I asked about multiple sorts above). So within each group you would have some consistency, plus the overall pattern to the groups.
The DB has the ability to sort on multiple fields at one go. The problem is that the GUI doesn't export it. If called for (performance), I can look at that. There are some issues, specifically getting the sort marks right. This won't happen today.
Quote:
I think it needs to be on the GUI front screen where it was originally. The other options on that search preferences are all "set once" type things whereas highlighting is something you are more likely to use on/off particularly if we start (ab)using it for functions like this plugin.
I ended up adding a tool button that toggles the option. The button's icon changes to show the current state. This takes up the least real estate and (IMHO) very usable.

To keep the icon correct, call
Code:
gui.set_highlight_only_button_icon()
after you set the preference to what you want. The above method takes care of notifying gui.library.model, so you don't need to do that any more.
Quote:
The behaviour will be that whenever the last duplicate group is resolved/marked not duplicate the gui will get "reset" in terms of restriction, highlighting mode and cleared search. I could also add a "clear duplicate results" menu item which would do the same thing, for if a user aborts resolving duplicates before the end. I would presume that for highlighting we should remember whatever setting the user had before they did a duplicates search - do we do the same for search restriction too?
Given the new button, I am not convinced that we (you) need to do anything complicated. I can see what is happening and fix it easily. This applies to the search restriction as well -- I can see that it is set and fix it easily.

Perhaps an 'I am done' menu item is sufficient? It would clear the search, clear (restore?) the search restriction, and restore the marking flag.
Quote:
Displaying the pairs is the tricky one. We are back to the old chestnut of trying to indicate to the user which is the "root". For instance we could just again use highlighting mode, set a restriction of "marked:not_duplicates", and then give you a menu option of "Show exemptions for this book" which then highlights all the books it is paired with. However as soon as they move their selection they will of course lose who the parent was. Buried two layers of menu down isn't exactly the easiest gui access too. And of course there is also the question of whether you would want this ability while looking at your duplicate groups, rather than only when looking at all your exemptions... I don't have any answers at this point, unless we go back to the idea of a separate dialog again for showing the exemptions?
A separate dialog might be the way to go here. As far as I can see, the only operation the user can perform is to break pairing for some number of books. The separate dialog could show the root on the top line, then show the others below along with a checkbox to indicate whether or not to remove that book from the not_dup set.

It could also be useful to be able to show exemptions as you describe, in order to give me the power of the GUI to see what is going on. Then, if I see a book that shouldn't be there, I would right-click on it to get the exemptions editor. That book would be the root, and I remove the offending books.

Does this work for you?
chaley is offline   Reply With Quote
Advert
Old 04-15-2011, 03:49 AM   #48
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: 11,703
Karma: 6658935
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
Quote:
Originally Posted by kiwidude View Post
@Charles potentially for this one (and yes I should raise a ticket but I'll ask about it first). Could the library view select_rows logic be tweaked (I know Qt has various options and it is something that bugs me from time to time).
Just submitted code to center the selected line (if possible).
Quote:
P.S. I see I just spent my 1000th post on wishing Kovid well. Only appropriate I guess.
1000 posts! You think this is your own playground? I wish you would stop using the limited number of bits available so that the rest of us can get a chance to wish him well too.
chaley is offline   Reply With Quote
Old 04-15-2011, 04:09 AM   #49
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: 11,703
Karma: 6658935
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
Quote:
Originally Posted by kiwidude View Post
@Charles - I don't suppose there is a convenient way to identify what the current sort column is? I discovered that sorting every time you move to the next duplicate group is quite slow. So what would be better I think (since the topmost sort column is that of "marked") is to check whether that is still the current top sort column, and only apply my sorts again of title then marked if it is not. The user can't sort on "marked" since it is not visible, so this should work as an optimisation.

I know from my ViewManager plugin that I can get down and dirty and roll around in get_state() with sort history etc, but I thought I would ask you first before I did that again to see if you had a better suggestion
No, there isn't. I could add a method to search for the column displaying the sort indicator, but I am not sure that is what you want. And in any event, it won't work for 'marked' because it isn't a column that can be made visible.

There be some dragons in using sort history or the proposed method. What that tells you is that the last time the view was sorted, it used columns X. It does not tell you that the view is currently in that order. For example, added books will go on top, which is probably not where they should be. I am not sure you should assume that the last sort is still good.

What I will look at is whether we can sort the filtered set (after search) instead of the entire cache. First blush look in the GUI says it will work there, because sorts are reapplied after a search. I don't know how the content server would treat this. Perhaps an option to db.sort would be best, so that the code that is prepared for this behavior can ask for it.
chaley is offline   Reply With Quote
Old 04-15-2011, 04:30 AM   #50
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: 11,703
Karma: 6658935
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
OK, I have changes that sort the sublist instead of the entire cache. Before I submit them (they are very small, so Kovid might be able to look at them), a question:

Without this change, searches operated on the sorted cache. library.caches.search generates a list of IDs, then order that list in the same way as the cache order. Because of this, it is not necessary to sort again after a search. However, if we are sorting the sublist (the search results), then the sort must be redone after every search.

Given that this matters only on a huge library, it isn't clear to me which is better. If searches tend to find large segments of the library, doing the sort again will be slower overall than what it is today. However, if the searches tend to find much smaller segments of the library, sorting the segment is a significant win. I can sort 400 records 100 times before I pay the cost of sorting 40,000 once.

Opinions?
chaley is offline   Reply With Quote
Advert
Old 04-15-2011, 04:50 AM   #51
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,601
Karma: 2092290
Join Date: Oct 2010
Location: Australia
Device: Kindle Oasis
Quote:
Originally Posted by chaley View Post
Without this change, searches operated on the sorted cache. library.caches.search generates a list of IDs, then order that list in the same way as the cache order. Because of this, it is not necessary to sort again after a search. However, if we are sorting the sublist (the search results), then the sort must be redone after every search.

Given that this matters only on a huge library, it isn't clear to me which is better. If searches tend to find large segments of the library, doing the sort again will be slower overall than what it is today. However, if the searches tend to find much smaller segments of the library, sorting the segment is a significant win. I can sort 400 records 100 times before I pay the cost of sorting 40,000 once.

Opinions?
What happens when a user clears the search and goes back to viewing all the books? Will that be slower than it is now?

From a search perspective I would have thought optimising for the 99% case of a far smaller search subset and having that displayed faster would be a nice win. I guess the question is "how much" slower is it for very large searches?
kiwidude is offline   Reply With Quote
Old 04-15-2011, 04:53 AM   #52
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: 11,703
Karma: 6658935
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
Quote:
Originally Posted by kiwidude View Post
What happens when a user clears the search and goes back to viewing all the books? Will that be slower than it is now?
Yes, because it must redo the sort, this time on the entire cache. Clearing the search will cost the same as a sort currently costs, where before it was close to free.

Edit:
Quote:
Originally Posted by kiwidude View Post
From a search perspective I would have thought optimising for the 99% case of a far smaller search subset and having that displayed faster would be a nice win. I guess the question is "how much" slower is it for very large searches?
The worst case slowdown is the time it currently takes to do a sort. One would pay that cost on every search, instead of only when sorting.

Last edited by chaley; 04-15-2011 at 04:55 AM.
chaley is offline   Reply With Quote
Old 04-15-2011, 05:18 AM   #53
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,601
Karma: 2092290
Join Date: Oct 2010
Location: Australia
Device: Kindle Oasis
Hmmm... not sure the sound of slowing down the display of "no search" sounds a good idea. If you have multiple secondary sort columns, is the penalty multiplied? e.g. by title/series/author?

I did find it a bit "laggy" when I was sorting each "next result group" with two calls to sort_by_named_field. If that is indicative of the extra time that will be added to every time you clear your search results it probably isn't the best to change this way.
kiwidude is offline   Reply With Quote
Old 04-15-2011, 05:24 AM   #54
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: 11,703
Karma: 6658935
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
Some numbers. On my 20,000 book test library

start with sorted by title
Without the change:
- search for 'foo'. Finds 48 records. Time: approx 2.5 seconds
- sort on author: Approx 1.5 seconds
- clear the search: Time: instant

With the change:
- search for 'foo'. Approx 2.5 seconds
- sort on author: instant
- clear the search: Approx 1.5 seconds

These numbers are consistent with the underlying changes. One pays for a complete sort when the search is cleared.

@kiwidude: there is one sort, no appreciable lag for multiple columns. The GUI knows to use the DB's multi-column sort in this case.
chaley is offline   Reply With Quote
Old 04-15-2011, 05:42 AM   #55
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,601
Karma: 2092290
Join Date: Oct 2010
Location: Australia
Device: Kindle Oasis
Interesting, thx for the numbers. The issue for me (and this is just my opinion) is that clearing the search is very much a part of the "99%" a user does in Calibre. Whereas in normal usage, they are far less frequently changing their sort column order.

Had this change allowed the cleared search to remain the same, speeded up small sorts but slowed down sorts of large search results then it would be brilliant Clearly there is a conflict.

I can't help wondering if "despite the dragons" we are instead not better off just trying to find another way to optimise for the type of behaviour I need for duplicate finder, that won't compromise general speed in Calibre today. For instance my idea of using sort history. I know you gave an example where the view contains added books - in this instance that is perfectly fine because I am refreshing the search and those books should disappear when that happens? And even if they didn't, letting them reamain at the top by not "re-sorting" is fine too?
kiwidude is offline   Reply With Quote
Old 04-15-2011, 05:47 AM   #56
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,601
Karma: 2092290
Join Date: Oct 2010
Location: Australia
Device: Kindle Oasis
Another possibility (though maybe this gets too complicated for doing) is could a background thread be used to sort the "rest of the results"? So if I "click away" in the gui, it is just sorting my local subset. In the background it is applying that sort to the rest of the data cache. Then when I clear my search, chances are it has already sorted them?
kiwidude is offline   Reply With Quote
Old 04-15-2011, 05:56 AM   #57
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: 11,703
Karma: 6658935
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
The thread would be difficult, because threading the GUI and the database is very hard.

I backed out the changes.

I was wrong when I said that adding a multisort would be complicated. It isn't. Try adding the following at the end of the books view class in gui.library.views (near line 730) and let me know if it works for you.

Call it using something like:
Code:
        self.library_view.multisort((('title',False), ('authors', True)))
where True means ascending and False means descending.

Code:
    def multisort(self, fields):
        if len(fields) == 0:
            return
        sh = self._model.sort_history
        for n,d in reversed(fields):
            sh.insert(0, (n, d))
        sh = self.cleanup_sort_history(sh)
        self._model.sort_history = [tuple(x) for x in sh]
        self._model.resort()
        col = fields[0][0]
        dir = Qt.AscendingOrder if fields[0][1] else Qt.DescendingOrder
        if col in self.column_map:
            col = self.column_map.index(col)
            hdrs = self.horizontalHeader()
            try:
                hdrs.setSortIndicator(col, dir)
            except:
                pass
chaley is offline   Reply With Quote
Old 04-15-2011, 06:04 AM   #58
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,601
Karma: 2092290
Join Date: Oct 2010
Location: Australia
Device: Kindle Oasis
Quote:
Originally Posted by chaley View Post
I would be happy with any of these. That said, I think that #2 is the best way forward, because of situation and workflow differences. My guess is that restriction+marking is best when working with a fairly clean library where the number of cases is small (probably what all of us have), vs a mess where there are 100s of duplicates. In the latter case, the user might prefer to deal with them group by group.
Cool, we will give #2 a try. It will be easy enough to change to one of the other options if we need to. So on the find duplicates dialog the user will choose whether they want to show all duplicate groups at once or one at a time. And every time they go "next result" it will reapply that "mode", just in case they got distracted into doing something else in between. The "Show all duplicates" menu will be removed.

Quote:
Sorting by fuzzy key is probably better than what I had in mind -- sorting by title_sort.
The only case I haven't addressed is a search for duplicate ISBN - since the fuzzy key is the ISBN number. What I could do is sort by the title_sort of the first book in each group if we think its worth it.

Quote:
I ended up adding a tool button that toggles the option. The button's icon changes to show the current state. This takes up the least real estate and (IMHO) very usable.
Yes I tried this and agree the toggle button works well. My only further suggestion was whether to colour the icon with green lines since that is what the UI gets marked with. Critical, obviously

Quote:
Given the new button, I am not convinced that we (you) need to do anything complicated. I can see what is happening and fix it easily. This applies to the search restriction as well -- I can see that it is set and fix it easily.

Perhaps an 'I am done' menu item is sufficient? It would clear the search, clear (restore?) the search restriction, and restore the marking flag.
So what I am thinking is the following:

1. Each time a user does "Find Duplicates" in a Calibre session, I remember what restriction and highlighting setting they had, and that is what I can restore to. The one exception will be if they do "Find Duplicates" while they are currently displaying duplicates (i.e. not "finished") in which case it will use the previous restriction/highlighting mode value. Perhaps I also need to remember their sort history to reapply, as once they exist duplicate mode then searching by "marked" as a primary sort would not be useful?

2. The user can exit the highlighting/restriction in any one of these ways.
- Manually clearing the restriction box/toggling highlight button
- Moving to the next group after merging the last groups contents
- Marking the last group as a duplicate exemption
- Marking all groups as duplicate exemptions
- Choosing a "Clear duplicate search results" menu option (I'm open to suggestions on the name!)

Quote:
A separate dialog might be the way to go here. As far as I can see, the only operation the user can perform is to break pairing for some number of books. The separate dialog could show the root on the top line, then show the others below along with a checkbox to indicate whether or not to remove that book from the not_dup set.

It could also be useful to be able to show exemptions as you describe, in order to give me the power of the GUI to see what is going on. Then, if I see a book that shouldn't be there, I would right-click on it to get the exemptions editor. That book would be the root, and I remove the offending books.
I like the idea of a popup dialog and a menu option of "Manage exemptions for this book". So as I understand it then that we still have the "Show duplicate exemptions" option, and that displays all the books that have exemptions (clearing the search restriction and highlighting mode, and just doing a search of "marked:not_duplicate").

That gives the user an unsorted list of books (well if they did this in the middle of finding duplicates they would still be sorted by title I guess). The user can pick a book and choose "Manage exemptions for this book" to view it's paired books and remove relationships. I guess I would also still keep the "Remove selected exemptions" menu item, so if a user wants to bulk remove for multiple books they can do so.

The "Manage exemptions" dialog will just display a grid with a small subset of columns like Title, Authors, Series, Tags and maybe Date. With as you say a checkbox column allowing the user to specify which of the rows after the first one to remove, and a select all button.

When I exit the "Manage exemptions" dialog, if the user made changes I refresh the search if they were showing "marked:not_duplicates". If they were showing a duplicate search result group (or anything else), there is no need to refresh. They can only get books "repartitioned" or "reappearing" by actually running Find Duplicates again.

The "Manage exemptions for this book" would be available on any book that was marked "not_duplicate". So in theory they could do it without entering the "Show all duplicate exemptions" search and instead do it while reviewing their duplicate groups. However it would be a bit of a random click fest as to whether they find that "Manage" menu item enabled or not as there will be no other visual indication that a book has duplicate exemptions. I'm hapy with that.
kiwidude is offline   Reply With Quote
Old 04-15-2011, 06:40 AM   #59
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: 11,703
Karma: 6658935
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
Quote:
Originally Posted by kiwidude View Post
The only case I haven't addressed is a search for duplicate ISBN - since the fuzzy key is the ISBN number. What I could do is sort by the title_sort of the first book in each group if we think its worth it.
Makes no never mind for me, as I don't use ISBNs.
Quote:
Yes I tried this and agree the toggle button works well. My only further suggestion was whether to colour the icon with green lines since that is what the UI gets marked with. Critical, obviously
I tried that. Problem is that I can't see the lines (green deficiency and the contrast isn't high enough to show grey). I can see the blue just fine and I have more posts than you, so I win.

Quote:
1. Perhaps I also need to remember their sort history to reapply, as once they exist duplicate mode then searching by "marked" as a primary sort would not be useful?
I don't think this is needed, but I am not against it.
Quote:
2. The user can exit the highlighting/restriction in any one of these ways.
- Manually clearing the restriction box/toggling highlight button
- Moving to the next group after merging the last groups contents
- Marking the last group as a duplicate exemption
- Marking all groups as duplicate exemptions
- Choosing a "Clear duplicate search results" menu option (I'm open to suggestions on the name!)
I am a bit concerned about some of these seeming to be magic. Will #s 2-4 be obvious? If not, then having the screen change suddenly might be odd.
Quote:
I like the idea of a popup dialog and a menu option of "Manage exemptions for this book". ...
This all sounds great.
Quote:
The "Manage exemptions for this book" would be available on any book that was marked "not_duplicate". So in theory they could do it without entering the "Show all duplicate exemptions" search and instead do it while reviewing their duplicate groups. However it would be a bit of a random click fest as to whether they find that "Manage" menu item enabled or not as there will be no other visual indication that a book has duplicate exemptions. I'm happy with that.
I can see the posts "I tried to mark two books as not duplicates, but it wouldn't let me. I marked them yesterday, so they are marked. Whats wrong with your software? Did your cockatiel change your keys?" Have fun.
chaley is offline   Reply With Quote
Old 04-15-2011, 06:54 AM   #60
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,601
Karma: 2092290
Join Date: Oct 2010
Location: Australia
Device: Kindle Oasis
Quote:
Originally Posted by chaley View Post
I tried that. Problem is that I can't see the lines (green deficiency and the contrast isn't high enough to show grey). I can see the blue just fine and I have more posts than you, so I win.
Haha, fair enough
Quote:
I don't think this is needed, but I am not against it.
I will avoid doing it then since not critical. Easy enough for the user to click a few column headings or just use the "View Manager" plugin
Quote:
I am a bit concerned about some of these seeming to be magic. Will #s 2-4 be obvious? If not, then having the screen change suddenly might be odd.
In each of cases 2-4 the user gets a dialog of some kind either telling them there are no more duplicate result groups or asking them to confirm that all results will be marked exempt. So they will have sufficient "warning" I think that the "job is done"?
Quote:
I can see the posts "I tried to mark two books as not duplicates, but it wouldn't let me. I marked them yesterday, so they are marked. Whats wrong with your software? Did your cockatiel change your keys?" Have fun.
Haha, that cockatirel one still cracks me up.
kiwidude is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Duplicate Detection Philosopher Library Management 114 09-08-2022 07:03 PM
[GUI Plugin] Plugin Updater **Deprecated** kiwidude Plugins 159 06-19-2011 12:27 PM
Duplicate Detection albill Calibre 2 10-26-2010 02:21 PM
New Plugin Type Idea: Library Plugin cgranade Plugins 3 09-15-2010 12:11 PM
Help with Chapter detection ubergeeksov Calibre 0 09-02-2010 04:56 AM


All times are GMT -4. The time now is 11:44 AM.


MobileRead.com is a privately owned, operated and funded community.