[Geany-Devel] RFC: Proxy plugins
kugel at xxxxx
Tue May 13 06:49:45 UTC 2014
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.
>> 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.
More information about the Devel