On 14-05-10 12:56 PM, Thomas Martitz wrote:
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, and it
requires a lot of changes to Geany (doesn't it?).
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 (it's not
actually that much new code, just a lot of refactoring) but also implies
a major plugin API breakage (while my proposal can be implemented
without API breakage).
I don't think it has to break the existing plugin loader interface, we
could make a parallel loader that integrates into the current Plugin
Manager UI and such. Just leave the existing C hooks in place (ie.
plugins.[c], pluginutils.[c], plugindata.h stuff) and maybe recommend
people not to use for new plugins. Most of the public API functions
could still be shared between core, old-style plugins and new-style
plugins (via some manner of bindings for the non-C ones).
Cheers,
Matthew Brush
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
