[Geany-Devel] RFC: Proxy plugins
kugel at xxxxx
Fri May 16 22:03:15 UTC 2014
Am 16.05.2014 19:32, schrieb Dimitar Zhekov:
> On Fri, 16 May 2014 16:59:17 +0200
> Thomas Martitz <kugel at rockbox.org> wrote:
>> I have a question regarding libpeas. There doesn't seem to be a public
>> (nor documented) API to add loaders. From what I can see the current
>> language support of libpeas is quite poor (only python and seed (that's
>> JS isnt it?)). Also, they don't seem to very committed to maintaining
>> their loaders.
>> I think we want to maintain the ability to add loaders on our own,
>> without depending on a 3rd party project. Especially for potentially
>> creating a compat-loader for our existing plugins. It doesn't seem
>> 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,
I found that too. But this is not public and not documented. It's also
not installed to /usr/include/libpeas-1.0.
Since we want plugin authors to be able to create loaders we need
something that's stable and documented.
> And for the next probable question, there is no search for .py files,
> instead the plugin .ini file (foo.plugin) specifies which loader should
> be used (C if missing).
I think this could be a problem too. Unless we maintain two loaders
(that would be better avoided) we need to find a way to have libpeas
find (and load) current plugins. Perhaps we could create a small helper
function that creates a suitable .ini (if it doesn't exist) out of the
current plugin_set_info() before running libpeas scan, for compatibility
More information about the Devel