Plugin Center

[jingkaimori]

Users should open a gui from mogan, which lists all plugins available for mogan, all plugins installed at local storage, and status of these plugins. Then users select plugin to install, update, remove or modify its setting.

When a plugin is detected, mogan should let user decide whether to activate the plugin. After activating plugin, mogan should tell user information and errors encountered in plugin execution.

Design of this tool should be discussed:

1. Where is plugins host by community We should build a service to host plugin archives.
2. Where is plugins stored on users' device Install to their user directory responding to each os. Different os has different standard:
   • windows: %APPDATA%
   • linux: a subdirectory of $XDG_DATA_HOME (or $HOME/.local/share if not defined)
   • macos: (Need Discussion)
   • wasm: (Need Discussion)
3. How to fetch and install plugins (Need Discussion) If a plugin is written in native language (c, rust, zig, .etc), binaries under different platform differs, thus proper package should be selected according to platform.
   1. ~We could fetch and install update via Qt Installer Framework~ Mogan is installed by apt on linux, or installed from portable version, thus QtIFW may be missing.
   2. We could make use of sparkle framework to update plugin.
   3. Users can also download plugin manually, and use mogan to extract and install plugin from download archive automatically.
4. Is it possible to hot-update plugins? (Need Discussion) Depends on module system
5. How to retrieve failure during plugin activation or execution? (Need Discussion)
6. How to localize a plugin? Where to store translations of text in plugin? Can we store these translation in dictionary of mogan? (Need Discussion)
7. Should we provide R7RS and SRFI interface for plugin written in scheme? (Need Discussion)
8. Should scheme script in plugins load external dynamic link library(DLL)? No. It is hard to learn dynamic linking for plugin developers. Developing dynamic loading api is also cumbersome. Evermore there is several security issues when loading dlls. (Need Discussion)
9. If a plugin is interface between texmacs and program outside(like maxima or giac), how to detect corresponding program? Where the information about entering program should be stored? (Need Discussion)
10. If a plugin is implemented in C++/Rust/... which could be compiled to wasm, we should deliver the binary in wasm but not one for Unix, another for Windows. But should we provide native binding (wasi) for these plugins? How to do with plugins depending on other libraries or applications that cannot be compiled to wasm? (Need Discussion)

[woutersj]

This is an excellent idea. I think we don't need to add much to improve a lot the user experience.

The following would already be great:

• a dialogue listing the installed plugins and their status (active/failed)
• a button to delete the selected
• a button to install a plugin from a zip file (with a confirmation to overwrite if the directory exists)

We can already download files from an url, but we can't unzip on all platforms. A minimal library like libzip could work well.

Additional information on why loading a plugin has failed would also be great, but I don't know if there is a mechanism to retrieve this.

[da-liii]

Where is plugins stored on users' device

On linux and macOS, the path will be changed. Currently, we are using $HOME/.Xmacs which is not a good place to install plugins.

[woutersj]

For Linux, a subdirectory of $XDG_DATA_HOME (or $HOME/.local/share if not defined) would be suitable.

[da-liii]

If a plugin is implemented in C++/Rust/... which could be compiled to wasm, we should deliver the binary in wasm but not one for Unix, another for Windows.

[hammerfunctor]

XDA_DATA_HOME to me feels more like a directory for persistent data, while downloaded plugins can be safely deleted. Making an analog to Emacs' elpa, we can store downloaded plugins in ~/.Xmacs/tspa (TeXmacs Scheme Plugin Archive), and add some mechanism like site-lisp to allow users to load plugins (possibly and other scm files) from directories they want.