[Geany-Devel] RFC: Proxy plugins

[Thomas Martitz]

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:
>
> On Sat, 10 May 2014 14:47:17 -0700
> Matthew Brush <mbrush at codebrainz.ca> wrote:
>
>> +1 for some form of introspection/code generation.
> Just to be clear: by "introspection", I don't mean *replacing* struct
> GeanyDocument with GObject GGeanyDocument and so on for the entire API.
> We may have a GGeanyDocument which represents (a) the GeanyDocument
> structure, (b) all document_*() functions as geany_document_*() and (c)
> all "document-" signals as "geany-document" with a GGeanyDocument
> argument. We can't generate signals for GGeanyDocument "fields" being
> changed directly from C, but we don't support such signals anyway.


That's two GeanyDocument APIs to maintain.


>
>> Am 10.05.2014 21:06, schrieb Dimitar Zhekov:
>>>> After that I'd say that LibPeas is perhaps something to be considered
>>>> for new application but not for our existing codebase. I think we want
>>>> something that enables proxy plugins while maintaining API and ABI
>>>> stability.
>>> peas does does you describe, and provides build-in loaders for Python
>>> 2/3 and JavaScript, i.e. standard languages. Please don't throw it away
>>> before even trying to adapt it.
>> As you have mentioned, even for C plugins it's a major change,
> I said moving a few strings to .ini, and adding a few macros.
>
>> and it requires a lot of changes to Geany (doesn't it?).
> It will require some changes, for example GGeanyDocument will not be
> straight-forward because of our organisation of the document list.
> Most will be additions though, with few (if any) API breaks.


So it does require non-trivial changes to the core, too?

>
>> 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.

>
>> ...but also implies a major plugin API breakage (while my proposal
>> can be implemented without API breakage).
> There will be small breakage for the .C plugins, but basicly all API
> function calls and structures will be the same. For Python, the object
> names will change. To make an omelette, you have to break the eggs.
>

No, you don't. This can be implemented without breakage (at least for C 
plugins, probably for existing python ones too).