The plugin architecture I've decided to use is quite simple, let me describe it briefly:
A plugin is implemented as a subclass of PyRoom.plugin_manager.Plugin() and needs to have certain attributes: [capabilities], a list of capabilities the plugin provides and, for each capability, a do_capability() method. Additionally, a plugin may override the builtin activate() method, which will be called when the plugin is loaded.
Plugins are stored in python modules that may contain multiple plugins. Modules containing plugins can be activated and deactivated, activating all plugins inside in the process. This is by design to allow bundling of plugins with features that depend on each other.
What's already been done
Currently, I've implemented a number of different hooks that call plugins by their capabilities in appropriate places of the code:
- on startup
- when the GUI has been set up completely
- when creating keybindings
- when buffer information is shown (i.e. Ctrl+I)
- before saving a file. It's possible to disable the standard file saving method here.
- after having saved a file
Plugins have access to both global objects state (including state['GUI'] and state['edit_instance']) and config.
There's quite a few opportunities for monkeypatching the GUI via plugins. This makes the system somewhat rough around the edges, but at the same time provides a lot of freedom to change things. Still, exceptions thrown in plugins, (hopefully) won't crash PyRoom, basic error handling displays a dialog box about the crashed plugin to the user and will offer to disable the plugin from now on.
What still needs to be done
I have a few plans for the plugin system.
First, we'll need some sort of a GUI for activating and deactivating plugins without restarting PyRoom.
Second, which is more interesting, would be a central repository for plugins users can browse and plugin developers can submit to. Updates included. The easiest way to do it would be to use Bazaar (because we use it for PyRoom development, substitute any other VCS, though..) for the plugins directory. File system permissions aren't a problem here, we'll just put it into the user's XDG home data directory. Still, we most likely won't be adding a dependency to a VCS to our simple text editor. We'll most certainly will be rolling our own solution here, although the VCS approach seems inviting.
Long story short, we'll have to integrate some sort of installation and update mechanism to the gui we're already planing.