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
On 31 January 2011 10:16, joshua.rh@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 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
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 01/30/11 15:49, Lex Trotman wrote:
On 31 January 2011 10:16,joshua.rh@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)
On 31 January 2011 11:54, Matthew Brush matthewbrush@gmail.com wrote:
On 01/30/11 15:49, Lex Trotman wrote:
On 31 January 2011 10:16,joshua.rh@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@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 01/30/11 17:14, Lex Trotman wrote:
On 31 January 2011 11:54, Matthew Brushmatthewbrush@gmail.com wrote:
On 01/30/11 15:49, Lex Trotman wrote:
On 31 January 2011 10:16,joshua.rh@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" ofthe 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): https://code.launchpad.net/~mars/+junk/geany-python-bindings
Cheers,
Matthew Brush (codebrainz)