Am 29.03.2015 um 19:17 schrieb Colomban Wendling:
Le 29/03/2015 00:23, Thomas Martitz a écrit :
- 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)?
I'll answer this question here in the hope the other thread can
concentrate on the new loader itself. But it also kind of depends on how
I designed the loader so I guess there will be some cross talk.
As with git master, Geany's core loader scans the plugin folder on
startup and on opening the PM dialog. For each recognized plugin file it
allocates a GeanyPluginPrivate and calls geany_load_module().
So this is where we come from:
- Geany initiates the scan (on behalf of the user)
- Geany has certain files it recognizes as plugins. It won't attempt
other files.
- Geany allocates and frees the structure that holds everything it needs
to know, this structure is opaque for actual plugins (and we need this
to be able to extend it)
So, to support pluxies as first class citizens, I designed it such that
Geany becomes able to scan additional files and hand the initialization
of plugins to the proxy (instead of calling geany_load_module()). The
idea is that Geany still performs the actual scan and builds up the
plugin list in the PM dialog, so it's completely synchronous. Geany
should still allocate the GeanyPluginPrivate structure for each plugin,
for the proxied ones too. Note that proxy plugins too call the same
geany_plugin_register() on behalf of the proxied plugins, like standard
plugins have to too. Geany fully supervises which plugins are loaded,
and when, so that it can provide a unified experience for the user,
regardless of the plugin type that's behind the scenes.
Therefore my mechanism is based on plugins letting Geany know which
files they can support, so that Geany's loader can scan for plugin files
like ever, except it can match more types, and calls into the proxy to
complete loading. For unloading the proxy is also called, to complete
plugin finalization. For this, plugins need a way to provide Geany with
the information it needs to load the additional plugins: file
extension(s), and load/unload callbacks (and a probe, to resolve
ambiguous file extensions).
To give a practical example:
with my new loader (no pluxies) it goes like this, and this is *very*
similar to git master.
> user opens PM dialog
1 Geany calls load_all_plugins(), which calls load_plugins_from_path($path)
2 for each $file in $path, Geany checks if the extension is
G_MODULE_SUFFIX, and calls plugin_new($file, ...)
3 plugin_new() calls the plugins's geany_load_module() (if new-style
plugin, calls version_check, set_info() for old-style ones)
4 geany_load_module() is implemented by the plugin, and registers itself
with geany_plugin_register()
< geany_plugin_register() adds the plugin to the plugin list, so that
the PM can sort and show it
Now, with pluxies, it is completely the same except for:
2* for each $file in $path, Geany calls is_plugin($file) which matches
additional file extensions (as provided by pluxies), it also calls the
probe() hook to resolve ambiguous files (e.g. .so files, they can be
core or libpeas plugins)
3* plugin_new() calls the load() hook registered by pluxies for the
given extension. for standard plugins (without proxy) there is a
predefined plugin_load_so() funtion that gets called instead.
4* The load-hook calls geany_plugin_register(), here Geany core and
proxies work the same way
I designed it such, that the difference between standard plugins and
proxied plugins is all contained in the load hook. The rest of Geany
does not know about the difference. This ensures proxied plugins are
first class citizens.
I hope you better understand my concept now. Let me emphasize again that
it's focused having relatively little impact on Geany's core or existing
plugins so that we can smoothly transition to a new non-C plugin world
full of joy!
Best regards
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
