[chaley]

Originally Posted by kiwidude

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.

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.

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.

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

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.

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.

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?