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