Am 11.07.2014 um 22:03 schrieb Colomban Wendling:
Le 07/07/2014 18:48, Thomas Martitz a écrit :
[...]
In my last post I've followed the approach of proxy plugins, aka pluxys. This approach is based on geanypy and implements a plugin API for plugins to act as proxy. I have mostly finished that (including an trivial example pluxy), and ported geanypy to this framework. The result is that with this approach I was successfully able to load python plugins with the core, including access to the plugin API, to the extend that geanypy allows plus keybindings via a new (experimental) API call. I think this should cover almost everything you would want for python plugins.
Since with that work you can successfully load python plugins I consider this approach workable.
Nice.
Now that the pluxy approach is in the final stages I went onto toying with libpeas.
[...]
There are three areas of problems with libpeas before we can adapt it, two of which I could already solve in a fork.
[...]
If using libpeas really requires having a modified version of it lying in our code, I'm not convinced it's a great idea.
FWIW, I did talk to the libpeas maintainer, Garret Regier. I cc'd him to get him into the loop.
Unsurprisingly, I met resistance to allow any changes that are only useful to load legacy plugins, I don't see any hope in this direction.
However, the Garret made a proposal that could enable us to load our existing plugins (using libpeas) without relying on any modifcations to libpeas.
Please note before juding that this needs only be done for non-peas-enabled plugins. We can peas-enable all of geany-plugins at compile time (using a mechanism not described here but which I already thought out) so this really does not apply g-p, but only out-of-tree plugins. And if it turns out we care too little about these out-of-tree plugins we can skip the whole backward-compat loading stuff and make an immediate switch to libpeas, and treat it like an ordinary API/ABI bump.
The proposal: 1) Scan the plugin dir for non-peas-enabled plugins (they can be distinguished by a) lacking a corresponding .plugin and b) missing the lib prefix in the filename) 2) For each of these, copy them to a user-writable dir (perhaps ~/.config/geany/XXX or ~/.local/lib/geany/XXX), if not already done by a previous session 3) Load the plugin into a special environment for the purpose of extracting it's metadata and generating a correspoding .plugin file. The environment can be a separate process (geany or separate binary) or within geany itself 4) Write the .plugin file for each to next to the copied plugin binary (can use GKeyFile API for that). *** The Module key needs to point to a wrapper binary that can provide the plugin entry point required by libpeas, I'll call it modlib. And the Module key needs to be unique across all available plugins, as required by libpeas 5) Load the plugin-specific modlib copy using standard libpeas apis
Point 5) is the most tricky. The modlib's job is only to load the actual plugin and create the gobject interface instance. It is suggested that the modlib implements the PeasExtensionBase [1] interface so that it can itself determine which actual plugin to load, by looking at its PeasPluginInfo. There needs to be a copy of the modlib for each actual plugin, to keep the Module key in the .plugin unique. And the modlib needs to register a unique GObject (GType) per plugin that libpeas instantiates (this would proxy the actual plugins exported functions).
Please comment on what you think.
[1]: https://developer.gnome.org/libpeas/stable/PeasExtensionBase.html