[Geany-Devel] RFC: Proxy plugins

[Thomas Martitz]

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:
>>> [snip]
>>>
>>> 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 
+260/-160 LOCs.

>
>> loaders+runtimes,
> again existing

Only geanypy, not javascript. And it'll require some more work to adapt 
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
> downsides.
>
> 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++ &
> Vala I guess), Python, javascript and something called seed are
> currently available.  I would really like to know what plans there are
> for others?
>

seed == javascript, IIUC

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 
javascript to the pool. Adding more language, which I would love to see, 
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.

Best regards.