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
- on Linux and Windows, opening the browser and stats window back and
forth multiple times triggers a crash in the GL libraries, even with
software rendering enabled. Will try again when .1 is out
- on Mac, shortcut keys fire multiple times:
https://bugreports.qt.io/browse/QTBUG-65184