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 <ku...@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
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
