[Geany-Devel] [Geany-Users] My non-C plugin roadmap

[Colomban Wendling]

Le 29/03/2015 00:23, Thomas Martitz a écrit :
> […]
> 
> - 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.

Agreed, but on the fact that it's not actually "also required for GI",
it's *only* required for this kind of thing.  It's good and everything,
but not required but for dynamically looking up the functions.

> - 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.

Agreed.

> - 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).

Agreed.

> - 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())

That's the part I'm really fuzzy about.  I really don't see why we need
this specific layer (maybe in an ideal world not bothering about how
Geany currently does it): as asked on the other thread, why do we need
anything beside geany_plugin_register() (required for everyone) and
geany_plugin_unregister() (required only when registered sub-plugins, as
the parent need to clean them up when it itself quits)?


Regards,
Colomban