[Geany-Devel] RFC: Proxy plugins

[Matthew Brush]

On 14-05-13 01:43 AM, Matthew Brush wrote:
> On 14-05-13 12:54 AM, Thomas Martitz wrote:
>> Am 11.05.2014 20:31, schrieb Dimitar Zhekov:
>>> On Sat, 10 May 2014 21:56:30 +0200
>>> Thomas Martitz <kugel at rockbox.org> wrote:
>>> [snip]
>>>
>>>> So why adapt peas when it requires a lot of changes *too* but also
>>>> severely breaks plugin API?
>>>>
>>>> I must be missing something, but it essence it appears to me that
>>>> adapting peas requires no less effort than what I propose...
>>> GeanyPy proxy = ~150 KB.
>>> 5 language proxies = ~750 KB, code that will have to be written and
>>> maintained. For comparision, geany/src/* = 1.9 MB.
>>>
>>> peas loader = ~15 KB, language support is in the core, and doesn't
>>> change with the new Geany versions, so you don't have to worry about
>>> any language(s) becoming unsupported/unmaintained.
>>>
>>> We must have Geany API (structures and functions) introspected for all
>>> new languages somehow. We can do that with large, manual, bug-prone
>>> per-language introspection, or with one GLib introspection.
>>
>>
>> Don't be ridiculous. This calculation is severely flawed and you know
>> that.
>>
>
> Well it is true we need this either way for non-C languages to interact
> with the API. In the case of GeanyLua, GeanyPy and most-likely your new
> "proxy plugins" it's all whole lot of C code which would probably be too
> much maintenance burden to be in core. This way is probably the worst
> approach.
>
> GObject-introspection would probably be the best approach, but for the
> existing exposed API functions/structs, would probably at the very least
> require changing doc-comments from Doxygen to GTK-DOC (plus adding some
> annotations), writing some override files to patch it up, and getting
> rid of the macros hiding function pointers that are members of
> structures stuff. This still wouldn't produce a "good" API for non-C
> languages (or C even), but it would at least make it not completely manual.
>

FWIW, I've been doing some experiments with libpeas as the loader in 
Geany (in my peas* branches on Github) and for the Python demo plugin 
(code not pushed to GH yet) I managed to get GObject-Introspection to 
scan Geany's source code/headers. Most of the work involved just 
"including what you use" and/or using defined names like `struct 
GeanyDocument` instead of `GeanyDocument` because the latter is defined 
off in some unrelated header. Once GI can grok one header at a time (ie. 
without pre-processing all the source together like C compiler does), it 
seems to pickup lots of the API (can't vouch for if or how well the 
bindings actually works yet).

Needs more experimentation/tweaking to be usable still though.

Cheers,
Matthew Brush