[Geany-Devel] RFC: Proxy plugins

[Thomas Martitz]

Am 10.05.2014 20:02, schrieb Dimitar Zhekov:
> On Fri, 09 May 2014 20:34:18 +0200
> Thomas Martitz <kugel at rockbox.org> wrote:
>
>> 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:
>>>
>>> Unless we are trying to enable scripting in more than a few languages,
>>> I see no reason for all these complications. [...]
>> 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 don't know the way to go, but there are two things we should not do:
>
> 1. Change the interface radically, gedit-style.


Do mean the GUI or API? If the latter, that's exactly what I want to 
avoid if possible. If the former, the proxy plugin work by itself 
doesn't add GUI changes.

>
> 2. Introduce serious code changes that won't benefit the users. Proxy
> plugins may be beneficial at some future point, or we may end up with
> several poorly-supported languages, and later with unmaintained proxies
> we dare not remove because that'll kill their sub-plugins.


Why do you claim there is no benefit for users? Seamless integration of 
non-C plugins is a clear benefit to me.

>> I suspect we would support 1 (or at most 2) proxy plugins ourself.
> I hope by "we" you mean the core plugins. Otherwise, that's no "support"
> at all.


Yes.


>
>> 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.
> The other proxy plugins will be DOA, except for mini-plugins (macros,
> scripts) that suit single users. Why should one bother to write a
> serious, mass-distributable sub-plugin in a 3rd party language, when
> there are official ones? To risk the proxy plguin being unmaintained?
>


Why DOA? I don't see that. I also don't see that there will be only 
small scripts/macro-style plugins.

I expect that plugin authors can make the best pluings if they are able 
to use their favorite language. So yes, I expect there will be some 
serious non-C plugins.

Best regards