[Geany-Devel] Proxy Plugins Update

[Lex Trotman]

To summarise our IRC discussion:

1. If the libpeas and the gobjectification can be split then I would
say  that would be the better way to do it, as two steps.

2. If changes required for core plugins and GP plugins can be
mechanised and don't require any changes by GP plugin maintainers then
those should be peasified as part of the release that supports
libpeas.

3. Support for third party plugins depends on how much of the
automation from the core/GP changes can be re-used by third party
plugin authors to minimise their efforts, compared to how much effort
is required to support them for one Geany release period (as described
below).  More info on exactly what each option entails is needed but
my gut feeling is that unless the effort is minimal it risks those
plugins being unavailable for a while after the geany release.

Cheers
Lex

On 12 November 2014 18:44, Thomas Martitz <kugel at rockbox.org> wrote:
> 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 at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel