[Geany-Devel] RFC: Proxy plugins

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

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

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

-- 
E-gards: Jimmy