Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shift editor control from Python to TypeScript #3830

Open
dae opened this issue Feb 18, 2025 · 0 comments
Open

Shift editor control from Python to TypeScript #3830

dae opened this issue Feb 18, 2025 · 0 comments
Labels

Comments

@dae
Copy link
Member

dae commented Feb 18, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant