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
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
