[Geany-devel] changes to the plugin interface

[Matthew Brush]

On 01/30/11 15:49, Lex Trotman wrote:
> On 31 January 2011 10:16,<joshua.rh at comcast.net>  wrote:
>> Hello,
>>            I'm not sure how high this is on the list of things to do, but I'd
>> like to work on it; so I'll make sure I'm headed in the right direction
>> before continuing.  I'd like the plugin interface to support python.  After
>> some time on irc it seems two of the best solutions would be 1) re-writing
>> the plugin interface to use gobject, or somehow refractoring the interface
>> to do use gobject.  This would allow us to support the languages gtk+ does,
>> but might have performance and maintainability issues.  The second (2) would
>> be weaving python in using the Python/C API.  This could provide more speed,
>> but would only support python.  Is it ok to only support python?  Or would
>> it be better to use gobject?  Or is there a better solution?  Thanks,
>>
>> Josh
> Hi Josh,
>
> I assume by "support" you mean be able to write plugins in Python?
> (ignore everything else if this fundamental assumption is wrong :-)
>
> My suggestion would be to extend (in a backward compatible way) the
> plugin API to allow plugins to have child plugins.  The child plugin
> appears to the user as if it is a first class plugin, but it is loaded
> and accessed only through its parent plugin.  The parent plugin would
> of course have the Python interpretor embedded in it and would expose
> the rest of the interface to Python and handle passing on callbacks.
This is the way my geanypy[1] plugin works (though I haven't touched in 
some time).  It's the "expose the rest of the interface" part I have 
troubles with.  I believe it was me on IRC who brought up the 
"GObject-ification" of the plugin API, since it would make 
GObject-introspection possible, which would mean automatic generated 
bindings of the API to all relevant languages (ex. Vala, Python, 
JavaScript, Genie, etc).
> This doesn't require changes such as GTKification to the current
> plugin interface that would invalidate all current plugins.
> This approach also has the advantage that it is actually independent
> of Python and someone could write a plugin to allow use of any other
> language and would allow to have both Python 2 and Python 3 versions
> so getting over that looming issue.
>
> Otherwise I would suggest a separate "python-plugins.c" file in core
> that finds loads and makes available the Python plugins embeds the
> interpretor and exposes selected Geany functions and structures to
> Python.
>
> Finally can I please remind all community members to keep discussions
> on the ML, IRC excludes people in other time zones from participating.
>
> Cheers
> Lex
>
The best solution in my mind is to use something like libpeas[2] in a 
proper Geany plugin, which takes care of loading the interpreters and 
such for multiple languages (and also provides a shared lib).  I already 
started this once with Ethos library[3] which turned out to be 
deprecated in favour of libpeas, even though it doesn't say that 
anywhere :).  This would replace the need for something like the Geanypy 
plugin for each language.  There's already a Vala bindings for Geany 
that Colomban wrote[4], so that takes care of Vala and Genie languages 
(maybe more?).  There's already a C api, so that's done.  Then we could 
write some PyObjects in C or Cython to expose the API to Python, which 
could be more "Pythonic" than GObject style bindings anyway.

[1] https://github.com/codebrainz/geanypy
[2] http://live.gnome.org/Libpeas
[3] http://git.dronelabs.com/ethos/about/
[4] http://gitorious.org/geany-vala-binding

Just my $0.02.

Matthew Brush (codebrainz)