[Geany-Devel] Proxy Plugins Update

[Thomas Martitz]

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