This reverts commit e1e0f2e1bd.
The previous change breaks the assumption on this line:
DeckKind::Filtered(_) => unreachable!(),
This will likely need a bigger refactor to handle this properly, and separate
out importing of deck configs from other scheduling data.
* Refactor: Add index to shapes package
* Add shape draw callback API to setupImageCloze
* Expose IO drawing API, switch away from image cloze naming
We currently use "image occlusion" in most places, but some references to "image cloze" still remain. For consistency's sake and to make it easier to quickly find IO-related code, this commit replaces all remaining references to "image cloze", only maintaining those required for backwards compatibility with existing note types.
* Add cloze ordinal to shapes
* Do not mutate original shapes during (de)normalization
Mutating shapes would be a recipe for trouble when combined with IO API use by external consumers.
(makeNormal(makeAbsolute(makeNormal())) is not idempotent,
and keeping track of the original state would introduce
additional complexity with no discernible performance benefit
or otherwise.)
* Tweak IO API, allowing modifications to ShapeProperties
* Tweak drawShape parameters
* Switch method order
For consistency with previous implementation
* Run Rust formatters
* Simplify position (de)normalization
---------
Co-authored-by: Glutanimate <glutanimate@users.noreply.github.com>
* Remove v1/v2 support from deck list
* Remove v1/v2 support from most routines and show error
* Remove scheduler_version from preferences
* Fix formatting
* Remove v1/v2 conditionals from Python code
* Fix legacy importer
* Remove legacy hooks
* Add missing scheduler checks
* Remove V2 logic from deck options screen
* Remove the review_did_undo hook
* Restore ability to open old options with shift (dae)
* Add text tool to IO
* Remove unnecessary parentheses
* Fix text objects always grouped
* Remove log
* Fix text objects hidden on back side
* Implement text scaling
* Add inverse text outline
* Warn about IO notes with only text objects
This will result in a different error message than the case where no
objects are added at all though, and the user can bypass the warning.
Maybe this is better to avoid discarding the user's work if they have
spent some time adding text.
* Add isValidType
* Use matches!
* Lock aspect ratio of text objects
* Reword misleading comment
The confusion probably comes from the Fabric docs, which apparently need updating: http://fabricjs.com/docs/fabric.Canvas.html#uniformScaling
* Do not count text objects when calculating current index
* Make text objects respond to size changes
* Fix uniform scaling not working when editing
* Use Arial font
* Escape colons and unify parsing
* Handle scale factor when restricting shape to view
* Use 'cloned'
* Add text background
* Tweak drawShape's params
* 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.
