On Sat, 10 May 2014 21:56:30 +0200 Thomas Martitz kugel@rockbox.org wrote:
On Sat, 10 May 2014 14:47:17 -0700 Matthew Brush mbrush@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.