Initially, I wanted to solve the bug reported on
https://github.com/Arthur-Milchior/anki-html-src-in-field/issues/1
After some research, I finally discovered that the trouble was that,
when we change the note type in add card, the method
`aqt.editor.Editor.loadNote` is called twice. In itself, it would not
be a problem, but given the way callback works, its call back is
called twice on the last version of the webview. Which means that
`gui_hooks.editor_did_load_note` is called twice, which breaks this
add-on.
The reason why loadNote is called twice is because `setNote` is called
twice in `aqt.modelchooser.onModelChange`. The first time through
`gui_hooks.current_note_type_did_change` which calls
`addcards.AddCards.onModelChange` which calls `loadNote`, the second
time through `self.mw.reset()` which calls
`gui_hooks.state_did_reset()` which calls `addcards.AddCards.onReset`
which calls `setAndFocusNote` which calls `setNote`.
I should note furthermore that currently,
`gui_hooks.current_note_type_did_change` is called only when the model
chooser change a model. And `addCards.onModelChange` is never called,
only added to the hook `gui_hooks.current_note_type_did_change`. So
removing the line of code removed in this commit will have no side
effect in Anki itself. It will only affect the fact that this method
is called twice.
I do not know of any add-on calling `onModelChange` or
`gui_hooks.current_note_type_did_change`, but it means little, so of
course, it may always mean an add-on will break because of this
change. No way of being sure.
A current problem I have is that there is nothing similar to hook
inside of javascript. It seems that it would be easier to be able to
add other methods in javascript and call them in loadNote. Currently I
simply redefined loadNote, which is far from perfect
Sometime I like to print html to understand why it bugs. And I really
prefer to have html indented if it's okay with you. There is no change
appart from the identation and quotes
This code was an awful hack to provide some semblance of UI
responsiveness while executing DB statements on the main thread.
Instead, we can just run DB statements in a background thread now,
keeping the UI responsive.
We were previously relying on the DB progress hook to cause the
progress window to display.
Qt's progress dialogs do have built in support for automatically
showing, but it's easier to add a timer than change the existing
code to use it.
