You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the editor is driven by editor.py. When the user selects a note,
or changes a notetype/deck in the add screen, our Python code sends a bunch of
JavaScript to the webview in loadNote(). This presents a number of problems:
It's messy - we have web implementation details leaking into the Python code
It's prone to race conditions due to the asynchronous message passing, and
so our code has hacks like sending the current note ID back to Python to ensure
they match.
It's a necessary step to being able to integrate the editor into a future
implemented-in-Svelte browse screen.
And most importantly, it makes integrating the editor into the mobile clients
impractical, since they would need to duplicate all the logic that we currently
have in the Python code.
I propose we shift the majority of the logic into the web end. For the editcurrent
and browser cases, the Python-visible API would consist of something very simple
like loadNoteId(bigint | null). That would cause the JS side to request all required
information via mediasrv, instead of editor.py being responsible for pushing note
data & metadata with eval().
For the addcards case, the editor would need to be wrapped in another Svelte component
that provides selectors for deck and notetype, as we currently implement them in Qt.
Some challenges we'll face:
Add-ons currently rely on Python hooks and monkey patching to alter editor behaviour,
and it may not be possible to preserve existing functionality in a backwards-compatible
way.
Copy/paste and drag & drop might be tricky. Are the JS APIs sufficient for us to handle
this (mostly) on the JS end? Or will we need to continue handling this separately for each
client, and sending messages to the webview?
Back when Henrik was actively involved, he made decent progress on some of these changes.
Unfortunately, I felt the changes were too disruptive at the time, and the PRs ended
up withering.
They've likely developed a bunch of conflicts since then, but they may still be useful
as a reference.
Since this is a fairly large change, I think we'll want to start with a basic proof of concept
to feel out the add-on and pasting issues (e.g. ignoring the addcards case for now) first.
The text was updated successfully, but these errors were encountered:
Currently, the editor is driven by editor.py. When the user selects a note,
or changes a notetype/deck in the add screen, our Python code sends a bunch of
JavaScript to the webview in loadNote(). This presents a number of problems:
so our code has hacks like sending the current note ID back to Python to ensure
they match.
implemented-in-Svelte browse screen.
impractical, since they would need to duplicate all the logic that we currently
have in the Python code.
I propose we shift the majority of the logic into the web end. For the editcurrent
and browser cases, the Python-visible API would consist of something very simple
like loadNoteId(bigint | null). That would cause the JS side to request all required
information via mediasrv, instead of editor.py being responsible for pushing note
data & metadata with eval().
For the addcards case, the editor would need to be wrapped in another Svelte component
that provides selectors for deck and notetype, as we currently implement them in Qt.
Some challenges we'll face:
and it may not be possible to preserve existing functionality in a backwards-compatible
way.
this (mostly) on the JS end? Or will we need to continue handling this separately for each
client, and sending messages to the webview?
Back when Henrik was actively involved, he made decent progress on some of these changes.
Unfortunately, I felt the changes were too disruptive at the time, and the PRs ended
up withering.
They've likely developed a bunch of conflicts since then, but they may still be useful
as a reference.
Since this is a fairly large change, I think we'll want to start with a basic proof of concept
to feel out the add-on and pasting issues (e.g. ignoring the addcards case for now) first.
The text was updated successfully, but these errors were encountered: