On 14-05-18 03:07 PM, Thomas Martitz wrote:
Am 17.05.2014 03:43, schrieb Matthew Brush:
On 14-05-16 03:03 PM, Thomas Martitz wrote:
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.
If it's designed for that, why doesn't it expose that to its users?
peas-plugin-loader.h is neither documented nor actually shipped, which
makes me think they want to keep their plugin architecture private
(subject to change). Given the GNOME community reputation that really
worries me because we totally want to add loaders to libpeas.
Because I guess they assume that if you're going to write another
language loader you're going to contribute it back to them. It would be
like adding a Scintilla lexer into Geany's source tree without
submitting it back upstream.
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`).
Yes, but these generally don't affect the plugin API. When we make
promises about the stability of the plugin API but depend on a 3rd party
to fullfill that promise it's not an ideal situation. Especially when
depending on the GNOME community as with libpeas.
This doesn't affect the plugin *API*. The only part that depends on how
peas does it is in the .plugin ini files stuff. Nothing in the plugin's
code even really has to know about Peas except maybe calling some type
registration function, it's just GObject interfaces after that.
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 :)
Yes I think that would be an acceptable solution once problems arise.
libpeas is pretty tiny isnt it?
I appears to be after some brief looking at the source code.
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.
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.
Yeah, this is actually a bonus for both C and non-C plugins. For one, it
means Geany doesn't have to actually load the .so files for C plugins to
read the plugin info, and additionally for not-C languages, it means the
engine can get metadata about the plugin without involving the loaders
(ie. no need to PyInitialize() the interpreter just to get metadata of
unloaded plugin in Plugin Manager GUI).
That being said, if we make existing plugin loader use .INI stuff it
will break all plugins, so maybe we could make some "opt-in" way that
doesn't.
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.
For b) I mean mostly just shuffling around/re-factoring code. You're
right about e), re-factoring it this way probably would improve its
encapsulation/isolation.
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.
As above, I presume the idea is that new loaders should be contributed
back upstream.
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.
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).
I think you're under-estimating the effort required, even not including
the proxy plugin changes you want to add in as discussed originally. The
(reverse) bindings stuff to call out to the non-C plugin languages, the
work involved in setting up their interpreters, and only loading them
when actually needed, a way to find meta-info about them without loading
them (and their interpreters), and probably much more (I guess just look
at libpeas source, most of it would have to be written, presumably).
But if libpeas can actually help us I'm happy to adopt it. I really mean
it.
I think it's a pretty good way forward without breaking existing loader
and it also happens work nicely with adapting GObject-Introspection for
auto-API-bindings, since that will auto-bind the peas extension points
(reverse of API bindings), making it actually usable from non-C/GObject
without extra work.
Cheers,
Matthew Brush
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
