Am 08.05.2014 19:25, schrieb Dimitar Zhekov:
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?
KISS.
Most plugins have UI. Loading plugins on demand means that the UI
will change dynamically, which is hardly a reason for celebrate.
- 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.
- 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?
- 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.
What???
No, this isn't about loading plugins on demand. This is about implementing APIs so that plugins (probably selected in the PM dialog) can act as a proxy to plugins written in other languages (also selected in the PM dialog). I do not intend to change the user experience w.r.t. to plugins: All plugins, regardless of the language, are user-selected in the PM dialog and loaded only then and on subsequent startups.
Best regards.