* Fix polygon not converting correctly to cloze
* Fix first polygon disappearing when creating se...
...cond one during editing
Previously, a fabric object was passed directly to a `Shape` such as
`Rectangle` or `Polygon`, so mutating a non-primitive property of the
shape would lead to mutating the original fabric object as well.
* Commit addition of polygon immediately
Unlike the rect or ellipse tools, when the polygon tool was active,
clicking on the canvas did not fire the `object:removed` event and the
`change` event was not dispatched. As a result, an addition of a polygon
was not saved to the DB when switching to another note or closing the
editor in edit mode without performing an action that dispatched the
`change` event.
* Rollback if toggling state fails
Previously, if the search triggered by a state toggle failed, the switch
and the model would move to the new state, while the table would remain
in the previous state.
* Fix reversed sort orders of FSRS columns
* Add sep. default sort orders for notes and cards
* Add test for consistent default sort orders
* Add launch config for debugging in VSC
* Extend launch config for macOS and Linux
* Refactor import apkg tests
* Merge conflicting notetypes regardless of id match
Original ids are a new thing, and we need to handle previous remappings.
This is done separately from the conflict resolution for notetypes with
matching ids, because 1) we need to look at the notes to determine
conflicts, and 2) we don't want to change the notetype of *all* existing
notes with the conflicting notetype. The main reason is that for 2
existing notes with the same noteype, their incoming counterparts could
have *different* notetypes. So to get rid of all conflicts, they must be
resolved on a note-by-note basis.
* Delete merged, now unused notetypes
Currently prop searches and the retrievability column will continue to
derive the days from the card only, as it's difficulty to integrate revlog
upgrade lookups into those code paths, especially in a performant way.
One possible way we could solve this in the future is to store last_review_day
in the card data, so we can know it even if the due date has been shifted.
Check DB could fill it in for existing cards.
* Draft set optimal/calculated retention button
Temporarily save the calculated optimal retention and display it with a button
that sets the desired retention above to this value.Don't show button until
attention had been calculated. Disable button when optimal and desired
attention are equal.
I find this nicer than the current alert-popup solution, as it avoids a popup
and gives a choice to the user to accept the calculated retention or not, while
also persisting the calculated retention on the screen for a bit.
TODO: What's still missing is that the `optimalRetention` variable is global and
persists when I change presets. When changing presets the variable should reset to
`undefined`, which would also makes the button disappear. Ideally it should also
disappear when changing the FSRS parameters. So probably it should be made part
of some deck options state and subscribe to some events. But with that I might
need some help. Also I thought whether that variable should go into the deck
options schema but tbh it's not something we want to persist between sessions,
users should recalculate it.
* Add me to contributors for tests so pass
* Add formatting ant type fixes to make tests pass
* Minor fixes (dae)
* Remove the period
It's very helpful having a sub-permille precision in a progress
indicator, percent-precision or at most a tenth of a percent should be
sufficient for any indicator.
But in particular the compute-retention progress has 10 steps, i.e. the progress
increases in 10%-intervals (10%, 20%, ...), it *cannot* have sub-decimal
progress-percentages, see 2d5b19b494/src/optimal_retention.rs (L365-L368). So there integer percents should be
enough, everything else is misleading.
The compute-weights progress is currently (as of beta-2) not showing up at all.
Maybe if the bug is fixed it can show sub-percent percentages, so for know I changed that
to 0.1% precision. But I think integer percentages should be fine here as well,
so upon request I can fix that.
Also see my comment on this problem in https://forums.ankiweb.net/t/anki-23-10-beta/34912/39.
