[Geany-Devel] RFC: Proxy plugins

[Thomas Martitz]

Am 09.05.2014 19:15, schrieb Dimitar Zhekov:
> On Fri, 09 May 2014 12:29:58 +0200
> Thomas Martitz <kugel at rockbox.org> wrote:
>
>>>> 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???
>>
>> 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.
> So then, the only remaining option seems that Geany will search the
> plugin paths, and match the found file extensions. It's unclear what
> call returns the sub-plugin metadata (name, version etc.), but that's
> solvable.

That hasn't been covered in the proposal but should work similar to the 
4 other hooks I mentioned.

>
> Unless we are trying to enable scripting in more than a few languages,
> I see no reason for all these complications. Let the master Foo plugin
> search for and probe the found .foo files, display a list of them, and
> save the list of selected ones in it's own configuration, without
> involving Geany. I'd like to have 100 useful python (lua, js, ...)
> scripts or macros, and will probably write my own, but certainly don't
> want them as first class plugins.

So what you are proposing is the status-quo (exactly what geanypy does 
right now). Apart from the limitations it to those plugins (keybindings) 
it does not integrate the plugins nicely into the PM dialog.

I accept that the status-quo is fine for you, but not for me and others. 
IRC discussions repeatedly indicated that proxy plugins are the way to 
go (the alternative is automagic bindings through gobject introspection 
which isn't feasible right now). I'd like to see serious plugins in 
other languages, and not just small scripts/macros. And I'd like to 
attract new contributors by offering a lower language barrier.

And because the core is more or less in maintenance mode (new features 
take *ages* to get in, if ever), we need to embrace plugin support even 
more.

> As another option, we can declare one scripting language as official,
> support the language binding for it, and provide the command console.
> Vim, emacs and gdb have one, so why should the light IDE Geany
> support N of them? And whoever wants to write a plugin to supports his
> or her favorite REXX/VBScript/younameit is still free to do so.
>
> Personally I'd choose a language that supports GTK+, *nix and Windows,
> for obvious reasons.
>


I suspect we would support 1 (or at most 2) proxy plugins ourself. Other 
proxy plugins can be maintained by third parties out of tree or in 
geany-plugins. I do not want to hard-limit the language choice to our 
blessed one though.

Best regards