There have been a few requests for “avogadro on the web” for a while, but that’s been hard since the codebase is in C++ with bits of Python.
Two big developments:
- Emscripten + WebAssembly => compile C++ to the browser
- Pyiodide => run Python in the browser
The catch, I think is that we’d want to make an avogadro-web project fairly modular. In other words, rather than having menus and option panels running through Qt, providing these as HTML + CSS so users can tweak them, integrate them into their website / JupyterLab / teaching system, etc.
In other words, I think an avogadro-web project would be a thin “frontend” to avogadrolibs much like avogadroapp:
- load up the 3D rendering panel
- load various tools
- load menus
- etc.
And then obviously it could then be configured with different toolbars (e.g., only key tools if wanted) or menu options (e.g., only view, build and select).
This means that we’ll want to migrate the tool options to generate JSON much like our plugins. That way a website gets the JSON (e.g., pick an element and bond order) and can render it in different ways with HTML and CSS rather than rely on Qt widgets through WebAssembly.
So what’s a “first minimal version” look like?
- 3D rendering
- navigate and edit tools
- open / save
I’m still debating some of this design in my head so I’d appreciate thoughts - as well as interest…
2 Likes
I feel like implementing the tools using a JSON-based API would be an unnecessary hit to performance for something that is being used constantly. Wouldn’t it be better just to generate bindings for the tools in an appropriate language that can then be used from JavaScript?
Naturally anything that’s on the web will probably want to have zero use of Qt Widgets. Perhaps it’s a good opportunity to improve the separation of concerns in the project. In an ideal world avogadrolibs would not depend on Qt Widgets (or Qt Quick) at all and everything UI-related would be in avogadroapp.
By my understanding the codebase leans on Qt Core a lot for general QoL stuff like QString, would that kind of stuff be an issue on the web? Would it not just compile to WASM using Emscripten?
I think you misunderstood. I was talking about a JSON-based API for providing the tool options - like picking the element or bond order for the draw tool. That way a web interface doesn’t need to use a Qt Widget for an options dialog. It can take the JSON representing the options and generate an appropriate HTML / CSS panel.
That’s not going to be practical. There’s already good separation in avogadrolibs itself, since only qtcore and qtplugins depend on Qt.
Moreover, an avogadroweb project would still want the same tools or it wouldn’t “feel” like Avogadro. It would just want a way to avoid using Qt-based dialogs. Even many menu commands would be just fine - you wouldn’t want to duplicate code for Copy / Paste / Select All, etc.
1 Like