[Geany-Devel] RFC: Proxy plugins

[Thomas Martitz]

Am 08.05.2014 19:25, schrieb Dimitar Zhekov:
> On Wed, 07 May 2014 23:58:11 +0200
> Thomas Martitz <kugel at rockbox.org> wrote:
>
>> Am 07.05.2014 19:59, schrieb Dimitar Zhekov:
>>> On Wed, 07 May 2014 08:40:13 +0200
>>> Thomas Martitz <kugel at 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.
>


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.