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