[Geany-Devel] RFC: Proxy plugins

[Lex Trotman]

[...]
>> After experimenting with this a bit, I believe it doesn't make much sense
>> to make a compatibility layer because a) you still need basically the same
>> code as the existing loader code, b) you would have to
>> change/refactor/re-write lots of it c) you would still have two distinct
>> ways to implement plugin interfaces, d) increases chances of breaking the
>> existing loader/plugins and e) intertwining the two loaders would probably
>> make it harder in the distant future to just drop one of them.
>
>
> The problem is that libpeas demands a different method of making plugins
> available (.ini vs known symbols in the .so file). We definitely want only
> one method, even if it means transitioning the symbol method to the .ini
> file.

Given the choice I would go for the .ini (or similar) method, I've
always worried that Geany is exposed to a crash risk by loading the
.so files (and so running the module init code) just to fill in the
PM.  Reading a text file is much safer.  And creating a text file for
existing plugins should be simpler than converting any of their code.

>
> I don't think b) is true, and for e) it would make it actually simpler if
> the one loader is just a plugin of the other one.
>
>
>
>>
>>>>> libpeas readily supports this. Unless I'm missing something.
>>>>
>>>> The loaders (except for C) are plugins, and the build-in ones are
>>>> installed in /usr/lib/libpeas-<version>/loaders/ as .so libraries.
>>>> For example, peas-plugin-loader-python.c contains:
>>>>
>>>> G_MODULE_EXPORT void
>>>> peas_register_types (PeasObjectModule *module) <-- as a regular plugin
>>>> {
>>>>    peas_object_module_register_extension_type (module,
>>>>      PEAS_TYPE_PLUGIN_LOADER,
>>>>      PEAS_TYPE_PLUGIN_LOADER_PYTHON);
>>>> }
>>>
>>>
>>> I found that too. But this is not public and not documented. It's also
>>> not installed to /usr/include/libpeas-1.0.
>>>
>>
>> Yikes! Free Software not properly documented! :)
>
>
>
> It's not just  a case of bad docs here. In this case it means it's not
> documented because it's private to libpeas, i.e. an implementation detail.
> For the same reason the peas-plugin-loader.h is not installed/distributed.
>
> While it has a plugin architecture for loaders it doesn't seem designed to
> allow for 3rd party loaders.
>
>
>>
>>> Since we want plugin authors to be able to create loaders we need
>>> something that's stable and documented.
>>>
>>
>> Then why do you want to write our own libpeas into the existing C plugin
>> loader? It will (at least for some time) be buggier, and less widely
>> tested/used/maintained (ie. only by us), take lots of extra effort, not
>> automate the bridge between core and the plugins' language, probably be less

Just to be clear, libpeas only automates the bridge to the *loader*
and the plugins, it does nothing for the interface between the
Geany/Scintilla functions and the plugins (and neither does Thomas'
proposal).

That binding is independent of the loader and should be the same
effort either way so long as the libpeas loaded plugins can get the
plugindata pointer somehow.  Then for C/C++/Vala its already done for
both options, and mostly done for Python2 by reusing geanypy's
bindings.

Automated bindings to Geany/Scintilla would be a huge step forward to
supporting other languages, but it is a separate problem from the
loader.

>> well-documented, and after all, the end result would most-likely provide an
>> inferior experience for non-C plugin authors.
>>
>
> I do not want to actually write that. However, I'm not convinced of libpeas
> yet (especially because if the .ini aspect), and then there's no alternative
> left. It only has to work well for us so I think the maintainance effort is
> manageable (and we'd have more control).

The only questions I have on libpeas is:

1. what changes it requires in Geany to make Geany keybindings usable
from libpeas loaded plugins, and
2. the effort to incorporate it into the existing PM.

IIUC Thomas' proposal would use the existing methods so it doesn't
require any changes in these areas.

Cheers
Lex

>
> But if libpeas can actually help us I'm happy to adopt it. I really mean it.
>
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel