[Geany-Devel] RFC: Proxy plugins

[Matthew Brush]

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.

Alternatives are such stuff as using SWIG, or having better manually 
maintained interface files (eg. .vapi file for Vala, cython or ctypes 
for Python, etc.) or rolling own Gobject-introspection system using 
Doxygen XML output/libclang/gccxml and a bunch of code generation 
scripts or something, none of which sounds very good, IMO.

Cheers,
Matthew Brush