[Geany-devel] changes to the plugin interface

[Lex Trotman]

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.

  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.

>>
>> 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?

Cheers
Lex

>
> [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)
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>