On 14-05-16 03:03 PM, Thomas Martitz wrote:
Am 16.05.2014 19:32, schrieb Dimitar Zhekov:
On Fri, 16 May 2014 16:59:17 +0200 Thomas Martitz kugel@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[1].
It doesn't seem to make much sense to support two JavaScript implementations, although I don't know the specifics of this.
I think we want to maintain the ability to add loaders on our own,
With Peas you can, in fact it's designed with this purpose in mind, unlike the existing C-only loader.
without depending on a 3rd party project. Especially for potentially
Meh, we depend on lots of 3rd party projects, several directly and many indirectly (see `ldd geany`).
Peas seems to be quite popular in the community around our framework/UI toolkit and is used by several (if not dozens) of popular applications, which also means it's readily available in many popular distros' package repositories.
Even if Peas becomes unmaintained/unsupported, we could roll it into our own source tree and maintain it like we do ctags and tagmanager and we still wouldn't have had to write it ourselves :)
creating a compat-loader for our existing plugins. It doesn't seem
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.
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! :)
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 well-documented, and after all, the end result would most-likely provide an inferior experience for non-C plugin authors.
Best regards.
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
We wouldn't have to maintain libpeas, it's a separate project with other developers maintaining it for us. Eventually in the long distant future (eg. Geany 2.0), we could drop the old loader and maintain zero loaders :)
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 purposes.
As mentioned above, this doesn't seem worth the trouble and I don't think it would be as easy/useful as it seems on the surface. We could just leave the existing loader without breaking anything, it's quite stable and works pretty well for plain C plugins that don't want to use GObject-ish stuff. We could document the Peas loader and related work as provisional while we get it all integrated and working well with the GI bindings and still leaving the existing stable C loader in-tact during this time and for the foreseeable future.
Cheers, Matthew Brush