[Geany-Devel] My non-C plugin roadmap

Lex Trotman elextr at xxxxx
Sun Mar 29 03:20:23 UTC 2015


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 at 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 at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel


More information about the Devel mailing list