The progress bar add-ons appear to be the only active users of it;
they can switch their old code from iterating over the list to
simply locating the selected deck in deckDueTree(), as its counts should
summarize all the child decks.
- front/back/css shown in tabs
- front/back preview switchable; only one webview needs to be loaded
- dropdown to select cloze number in preview
- search box to search in front/back/css
Saves having to serialize the note fields and q/a templates, which
is particularly a win when rendering question/answer in the browse
screen.
Also some work towards being able to preview notes without having to
commit them to the database.
Previously if the sum of child counts was above the parent's limit,
the deck tree would show a parent count above the parent's limit, and
clicking on the parent would show a lower count. The new deck tree
code never shows a parent count above the parent's limit, so this
part of the test is no longer valid.
- notetypes are fetched from the DB as needed, and cached in Python
- handle note type changes in the backend. Multiple operations can now
be performed in one go, but this is not currently exposed in the GUI.
- extra methods to grab sorted note type names quickly, and fetch by
name
- col.models.save() without a provided notetype is now a no-op
- note loading/saving handled in the backend
- notes with no valid cards can now be added
- templates can now be deleted even if they would previously
orphan notes
a number of fixmes have been left in notes.py and models.py
While it makes no sense to have the typing box on the front without
another non-empty field, "the front of this card is empty" when
a typing box is on the template seems to be confusing some users, so
it is clearer to show them the box.
Disabled for now; when enabled it will allow faster collection
open and close in the normal case, while continuing to downgrade
when exporting or doing a full sync.
Also, when downgrading is disabled, the journal mode is no longer
changed back to delete.
- all .ftl files for a language are concatenated into a single file
at build time
- all languages are included in the binary
- external ftl files placed in the ftl folder can override the
built-in definitions
- constants are automatically generated for each string key
- dropped the separate StringsGroup enum
The parsing step is considerably slower in Python, but if parsing
is moved out of the test function, Python wins at 45ms to Rust's 67ms
on 10,000 rounds, presumably due to the overhead of serializing to
Protobuf. Not enough of a difference to justify the inclusion of extra
dependencies and duplicating the lookup code in any case.
