Thomas,
Thanks for that, it now makes it clearer where you are going, and allows the individual steps to make more sense.
I agree with your four problems (shortened):
- linkage - keybindings - plugin context - allow for proxies
My concern is that the solutions seem complex, though, having followed your attempts over time to address these issues, I do understand that some of the "simple" options don't actually cut it.
Will need to think on it further.
Cheers Lex
On 29 March 2015 at 10:23, Thomas Martitz kugel@rockbox.org wrote:
Hello,
I was asked to share a bit about my roadmap regarding plugins. I'll try to give you a better idea with this post.
My ultimate goal is to implement a clean and maintainable way to support non-C plugins, preferably using existing widely used techniques. I concluded that libpeas[1] in conjunction with gobject-introspection can provide the base for this. Since Geany is not at all prepared for this I have several infrastructure which I do want to get merged into Geany. When Geany core is sufficiently setup for this, the non-C plugin enablement can happen outside the core, as a plugin, to stabilize there.
So, here's the set of infrastructure changes for the core. Please let me stress that all of this will happen in backward-compatible manner, no existing plugins break as part of this.
- linkage-cleanup (PR#429) - This changes the way plugins access Geany API
functions. Instead of exporting a pointer to a struct of structs of API function pointers, now the APIs are exported directly. This work also includes an effort to stop exporting all function (we do this currently as a workaround to allow gtkbuilder to work), so *only* API function are exported and plugins cannot call internal function anymore. This change is also required to allow gobject-introspection to find geany functions at runtime (through g_module_symbol()) in the future.
- new API functions for registering keybindings (PR#376). The current API
functions do not allow context information to be stored and passed to the key handler function. This makes it very hard for non-C plugins to use these function. So what's needed are key handlers that get the necessary context information. This allows interprepted language plugins to register keybindings.
- A new plugin loader mechanism (a thread about this is already running on
the devel list): Similarly to the keybindings, the plugin_* functions implemented by plugins do not carry any context information, making it hard for non-C plugins to implement them properly. Therefore a new loader mechaism is needed so that the context information can be passed. The loader works such that an API function is called to register a function pointer table. This is crucial to possibly support plugins that register other plugins (so called pluxies) which is simply not possible with the current mechaism. The current loader is kept for backwards compatibility (but will not receive new features).
- New API functions to allow plugins to act as proxy plugins (pluxies).
These pluxies can then implement whatever is needed to execute code in the in the actual plugin, like invoking an interpreter or firing up a java vm. The pluxies call the new loader's API function on behalf of the actual plugin. The API function to implement the pluxies is a simple geany_register_pluxy() that, much like the normal plugin loader, that pluxies use to pass a function pointer table which implements the necessary hooks (probe(), load() and unload())
Once this is in place in the core, my roadmap contains the following items, which are implemented (at least initially) in a plugin, so no further changes to the cure should be necessary.
- Modify geanypy to use the new pluxy APIs. This will finally enable geanypy
to show the python plugins in the normal PM dialog and support keybindings
- Create a new pluxy that supports libpeas-based plugins (codename: peasy).
Peasy will use libpeas to load plugins and their metadata.
- Part of the peasy work is also work on creating vala and
gobject-introspection bindings for Geany's API functions, so that we can support python, javascript and lua out of the box.
This is my roadmap so far. It changed quite a bit since I started this non-C-plugins effort a year ago, but I hope it will be good for everyone. Please share your opinions on this or ask questions.
Best regards. _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel