[Geany-Devel] RFC: Proxy plugins
kugel at xxxxx
Mon May 19 12:17:56 UTC 2014
Am 19.05.2014 13:13, schrieb Lex Trotman:
> On 19 May 2014 19:58, Matthew Brush <mbrush at codebrainz.ca> wrote:
>> On 14-05-18 10:10 PM, Lex Trotman wrote:
>>> 2. the effort to incorporate it into the existing PM.
>> I don't think this will be very difficult, even from me who loathes
>> GtkTreeView :)
>>> IIUC Thomas' proposal would use the existing methods so it doesn't
>>> require any changes in these areas.
>> But it requires writing own libpeas (ie. scanners,
> Unless I have misunderstood Thomas (have I?) he is using the existing scanner.
Yes, you got this right. And I have already done it locally with
> again existing
to the new core infrastructure.
>> +gobject-introspection-bindings, etc).
> As said in my previous post, bindings have nothing to do with the loader.
That's right. The bindings question is orthogonal to the
loader-infrastructure one. But I think Matthew is working on
autogenerating bindings which is great (I'll try to help where I can).
Then we can focus on the loader question more easily.
> The main difference between the two options is that libpeas can
> provide loaders for new languages simply (as shown by Matthew loading
> Python3) but at the cost of having to integrate something very
> different to the current system, whereas Thomas' proposal is a simple
> extension of the existing system to fix Geanypy problems but doesn't
> offer loading of any extra languages without further effort.
Another key difference is that in my proposal the loaders are also
normal plugins (I call them pluxys) that use the same infrastructure
(and therefore appear in the PM dialog). The pluxys can therefore offer
more that just proxying (though I would not recommend it) and can easily
be maintained by a third party. With libpeas, they come with libpeas and
are separately enabled/disabled (though we could probably work the peas
loaders into the PM gui somehow). On the other hand, it might be
preferable to separately manage pluxys.
Yet another key difference is the .ini file approach used by libpeas vs.
fixed symbols in the .so files used by Geany. I too think the .ini
approach is superior but unfortunately it's a break for existing plugins.
> To my mind both approaches have their good points, and both have their
> As I said before, I am not able to pick a best solution at this point.
> To my mind the important question is "how hard is it to change Geany
> to allow libpeas loaded plugins to register keybindings?" with the
> secondary question of the PM as well (its more the interface from peas
> to the PM code than the treeview, since it has to work with existing
> plugins as well). If those potential problems are solved then libpeas
> may provide a faster path to more languages, though only C (so C++ &
> currently available. I would really like to know what plans there are
> for others?
I don't know what the plans are but libpeas doesn't appear to be
actively developed. The last mailing list activity is from may 2012. It
was a question by an ubuntu developer, and it remained unanswered. The
git log is only slightly more promising.
So I absolutely do not expect that libpeas will add new languages in the
short-mid term (or change at all), so (from our POV) it only adds
will require effort from our plugin authors. And I expect we would need
to clone/fork libpeas (similar to scintalla) because the APIs to add
language loaders are not public and presumably unstable (but again, I
don't expect libpeas to change at all due to inactivity).
Sorry if I sound negative towards libpeas. I'm not fundamentally against
it. I try to objectively evaluate it, and it doesn't appear to be the
holy grail either, especially with our strong focus on maintaining the
plugin ABI/API and exposing the current API via bindings.
More information about the Devel