* Allow im-/exporting with or without deck configs
Closes#2777.
* Enable webengine remote debugging in launch.json
* Reset deck limits and counts based on scheduling
Also:
- Fix `deck.common` not being reset.
- Apply all logic only depending on the source collection in the
gathering stage.
- Skip checking for scheduling and only act based on whether the call
wants scheduling. Preservation of filtered decks also depends on all
original decks being included.
- Fix check_ids() not covering revlog.
* Fix importing legacy filtered decks w/o scheduling
* Disable 'include deck options' by default, and fix tab order (dae)
* deck options > deck presets (dae)
* Remember original id when importing notetype
* Reuse notetypes with matching original id
* Add field and template ids
* Enable merging imported notetypes
* Fix test
Note should be updated if the incoming note's notetype is
remapped to the existing note's notetype.
On the other hand, it should be skipped if its notetype id is mapped
to some new notetype.
* Change field and template ids to i32
* Add merge notetypes flag to proto message
* Add dialog for apkg import
* Move HelpModal into components
* Generalize import dialog
* Move SettingTitle into components
* Add help modal to ImportAnkiPackagePage
* Move SwitchRow into components
* Fix backend method import
* Make testable in browser
* Fix broken modal
* Wrap in container and fix margins
* Update commented Anki version of new proto fields
* Check ids when comparing notetype schemas
* Add tooltip for merging notetypes.
* Allow updating notes regardless of mtime
* Gitignore yarn-error.log
* Allow updating notetypes regardless of mtime
* Fix apkg help carousel
* Use i64s for template and field ids
* Add option to omit importing scheduling info
* Restore last settings in apkg import dialog
* Display error when getting metadata in webview
* Update manual links for apkg importing
* Apply suggestions from code review
Co-authored-by: Damien Elmes <dae@users.noreply.github.com>
* Omit schduling -> Import all cards as new cards
* Tweak importing-update-notes-help
* UpdateCondition → ImportAnkiPackageUpdateCondition
* Load keyboard.ftl
* Skip updating dupes in 'update alwyas' case
* Explain more when merging notetypes is required
* "omit scheduling" → "with scheduling"
* Skip updating notetype dupes if 'update always'
* Merge duplicated notetypes from previous imports
* Fix rebase aftermath
* Fix panic when merging
* Clarify 'update notetypes' help
* Mention 'merge notetypes' in the log
* Add a test which covers the previously panicking path
* Use nested ftl messages to ensure consistency
* Make order of merged fields deterministic
* Rewrite test to trigger panic
* Update version comment on new fields
* Automatically elide empty inputs and outputs to backend methods
* Refactor service generation
Despite the fact that the majority of our Protobuf service methods require
an open collection, they were not accessible with just a Collection
object. To access the methods (e.g. because we haven't gotten around to
exposing the correct API in Collection yet), you had to wrap the collection
in a Backend object, and pay a mutex-acquisition cost for each call, even
if you have exclusive access to the object.
This commit migrates the majority of service methods to the Collection, so
they can now be used directly, and improves the ergonomics a bit at the
same time.
The approach taken:
- The service generation now happens in rslib instead of anki_proto, which
avoids the need for trait constraints and associated types.
- Service methods are assumed to be collection-based by default. Instead of
implementing the service on Backend, we now implement it on Collection, which
means our methods no longer need to use self.with_col(...).
- We automatically generate methods in Backend which use self.with_col() to
delegate to the Collection method.
- For methods that are only appropriate for the backend, we add a flag in
the .proto file. The codegen uses this flag to write the method into a
BackendFooService instead of FooService, which the backend implements.
- The flag can also allows us to define separate implementations for collection
and backend, so we can e.g. skip the collection mutex in the i18n service
while also providing the service on a collection.
