On Wed, 07 May 2014 23:58:11 +0200 Thomas Martitz kugel@rockbox.org wrote:
Am 07.05.2014 19:59, schrieb Dimitar Zhekov:
On Wed, 07 May 2014 08:40:13 +0200 Thomas Martitz kugel@rockbox.org wrote:
I'm (as of now) motivated to implement proxy plugins (to my amusement, until splitwindow2 gets finally reviewed...). Therefore I would like to receive comments on my proposed concept and APIs (further below).
Feasible, but... why? Looks a bit like GTypePlugin to me, with it's proxied "dynamic" classes, and nearly zero implementations.
I'm not sure what GTypePlugin has to do with it. This isn't about loading new GObject classes dynamically (proxy plugins aren't GObjects).
It's not directly technically related, of course, just seems smiliar as a mechanism, and as something without purpose.
Perhaps you can elaborate a bit?
1. KISS.
2. Most plugins have UI. Loading plugins on demand means that the UI will change dynamically, which is hardly a reason for celebrate.
3. Why can't one simply mark the plugins (s)he needs statically? If there are any compatibility or resource usage problems, they should be fixed in the original code, instead of relying that Geany will work better by loading a smaller set of plugins on demand.
4. If we need dynamic loading (though I don't know of any reason for that), why not extend the standard plugin API with criterias, and let the "plugin enabled" checkbox in the PM dialog have a "half-checked" position for plugins with criterias? Why proxiyng?
5. How do we choose which sub-plugins of a proxy plugin should be enabled - a tree structure N levels deep? Obviously, one may not be satisfied with the activation criterias, and may want specific sub-plugins explicitly enabled or disabled.
It seems to me that your idea mixes dynamic loading and proxying. These are not actually related (except for the fact that the criterias, if implemented, should be appliable to the sub-plugins, if implemented).
The basic idea is that proxy plugins initially call a Geany API to register themselves as proxies, providing criterias to select potential plugins (for now, this is only a list of file extensions)
Geany will match files against these criterias and, on match, call into the plugin for the first time.
What exactly will it match - the extensions from the files in the current session? So the PM dialog will contain a different list of plugins each time it's open? And yet different list on startup, since plugin_init() is before any files are loaded? Perpahs I don't get your idea at all.
Then when Geany generates the plugin list (i.e. when the user opens plugin manager (PM) dialog) it'll call a second time into the proxy. This time the purpose is to load the actual plugin, and install plugin-specific init(), configure(), help() and cleanup() hooks.
An what happens if the user simply doesn't open the PM dialog - the actual (sub-?)plugin is never loaded?..
I'm not against specific proxies - loading the interpreter or runtime Foo once, instead of a copy for each plugin written in/with Foo, makes sense. But that seems different from what you described, and the sub-plugin search and choosing should be done by the master Foo plugin, using the Foo language and/or runtime. Unless we are trying to build language bridges for the sake of it, there will hardly be more than two or three of those plugins.