[Geany-devel] changes to the plugin interface
matthewbrush at xxxxx
Mon Jan 31 00:54:41 UTC 2011
On 01/30/11 15:49, Lex Trotman wrote:
> On 31 January 2011 10:16,<joshua.rh at comcast.net> wrote:
>> 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,
> 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 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,
> 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
> Finally can I please remind all community members to keep discussions
> on the ML, IRC excludes people in other time zones from participating.
The best solution in my mind is to use something like libpeas 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 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, 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.
Just my $0.02.
Matthew Brush (codebrainz)
More information about the Devel