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 <ku...@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
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
