[Geany-devel] changes to the plugin interface

Matthew Brush matthewbrush at xxxxx
Mon Jan 31 05:40:57 UTC 2011

On 01/30/11 17:14, Lex Trotman wrote:
> On 31 January 2011 11:54, Matthew Brush<matthewbrush at gmail.com>  wrote:
>> 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).
> Hi Matthew,
> I knew that there were previous attempts but I didn't know where they got to.
> It's the "expose the rest of the interface" part I have troubles
>> with.
> I'm no expert on Python interfacing, but I can see how the
> "pointerification" of the plugin interface, whilst flexible, can make
> binding difficult.
Precisely.  I'm sure to some it would not be difficult.
>     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).
> I can see the benefits, can this be done as an extension of the
> interface so that the current one can be deprecated but still be
> available for a couple of years?
> That way current plugins don't have to be re-written immediately.
I think it *has* to be done on-top of or along side the existing plugin 
API for the reasons you said.
>>> 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]
> Looks like a way of reducing effort.
>   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.
> Ok.
> 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.
> Yes, this is the problem, I guess if it was easy you would have done
> it in GeanyPy?
Pretty much.  When I get some time though, I'll revisit this, as it 
might not be too tough.  In all cases it needs to be done.  There's also 
someone who's code I based mine on, might be some useful stuff for 
bindings in there (I found this in the ML archives):


Matthew Brush (codebrainz)

More information about the Devel mailing list