[Geany-Devel] RFC: Proxy plugins

[Steven Blatnick]

I sent this email earlier and never saw it come back through the mailing 
list, so I'll send it a gain to see if it is going through...

...

Like I think Dimitar was saying, adding custom scripts sound like they 
should be second class plugins.

Sorry to be a broken record here, but my external tools plugin calls 
whatever language you can make an executable for or call from the 
command line: 
https://github.com/sblatnick/geany-plugins/tree/external-tools/external-tools/src 


I don't see the need for bindings for every language to tap into plugin 
functionality when you can call scripts and accept the scripts output 
with some accepted criteria, kinda like an API or like my plugin does.  
For instance, external-tools lets you output a program to the bottom 
panel or substitute currently selected text in geany, etc.  While this 
limits the methods the plugin can interact, it supports an easy input 
and easy output logic.

I haven't been following the entire thread, and I don't mean to come 
across as continuously advertising my own plugin, but it seems to me 
that you are discussing integrating other languages to the plugin 
structure.  In my opinion, this plugin already does that to a limited 
extent, but to an extent that meets my needs as I'm not looking to tweak 
UI from the plugin.

Just as I think Dimitar was saying, I don't think we want to overly 
complicate plugins because of wanting to support "everything" or every 
language for plugins.  I hope changes to how we do plugins don't break 
existing plugins too much, as that was one of the reasons I left gedit.  
It's annoying rewriting plugins because of the changes.

Thanks,

Steve



On 05/09/2014 11:15 AM, Dimitar Zhekov wrote:
> 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.
>
> 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.
>
> 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.
>