We can't preserve the original queues when in preview mode, as
otherwise the due counts report the remaining steps of cards in
the learning queue, instead of just 1.
Rather than the rather complicated approach of making the learning and
deck list code aware of the current mode we're in, preview mode moves
all cards to the review queue when the filtered deck is built - just as
cards are moved to the new queue in Anki 2.0.x. The reason for the
review queue is that users were frequently confused when cards appeared
as new - hopefully this is slightly less confusing.
with autosync on, when the progress dialog is closed and the main window
appears, it becomes stuck. hiding the dialog instead of closing it
seems to fix this.
- fetch reviews from all child decks at once, sorted by due order
- shuffle the gathered cards as we did previously
- review limits on child decks are ignored - only the current deck and
its parents control what the limit is
- to make the deck list consistent with actual counts, we can't sum the
child counts, as the sum in the parent limit>child limit case may not
reflect the actual number of cards that would be presented
the previous approach meant we weren't able to preserve the card state
exactly when cards were in learning, since we didn't record the step
position prior to cards being moved into the filtered deck.
it also meant the answer buttons needed to change depending on state - 4
for cards in learning/review, but 2 when the card is on the final step
or is a review.
instead, in preview mode cards always have 2 buttons: again will repeat
again after a delay, and good immediately removes the card and restores
it to its previous state.
to accomplish this, we use a separate queue #, as the learn count
always needs to have a 1:1 correspondence to the number of cards
- move fuzzing into _constrainedIvl() so it's applied prior to limits
like maxIvl
- don't fuzz early reviews, so cards get the same interval if a filtered
deck is rebuilt again
Handle definition of context menu in same way that shortcutKeys are handled. This makes it easier for add-ons to modify the context menu without needing to re-implement the whole showContextMenu method.
qprogressdialog has been the source of a number of problems in the past,
and the most recent issue is that it's showing the progress dialog
early, regardless of what the minimum duration is set to. since we're
already using our own logic for deciding when to show the dialog, it's
easier to move to a normal dialog box
also prevent timers from firing while a progress dialog is visible, or
if the refresh timer fires we end up with the same issue.
https://anki.tenderapp.com/discussions/beta-testing/949-anki-stops-when-field-is-added
