Hi there,
I'm now hacking python for about two to three years and I'm willing to wrap that plugin api to python. Browsing the geany site I noticed that you want such an api as well, so my question is: Are there any special plans for that interface? Or shall I just take the C api and wrap it?
Cheers, Jonas
On Sat, 06 Jun 2009 13:31:15 +0200 Jonas Haag jonas@jonashaag.de wrote:
I'm now hacking python for about two to three years and I'm willing to wrap that plugin api to python. Browsing the geany site I noticed that you want such an api as well, so my question is: Are there any special plans for that interface?
No, it's just a wishlist item.
Or shall I just take the C api and wrap it?
It's a bit complicated. Geany doesn't have a shared library for plugins to link against, instead, Geany sets symbols like geany_functions in each plugin before initialization. Plugins use generated macros to call Geany functions.
http://www.geany.org/manual/reference/plugindata_8h.html
So I'm not sure how a python plugin could work, but I'm no expert ;-)
Regards, Nick
Am 06.06.2009 13:52, schrieb Nick Treleaven:
It's a bit complicated. Geany doesn't have a shared library for plugins to link against, instead, Geany sets symbols like geany_functions in each plugin before initialization. Plugins use generated macros to call Geany functions.
So this is like "I create a plugin with C functions in it, register that plugin and geany calls that functions"?
I planned to write a wrapper in C that calls functions of a python module which handles all the other stuff (I'll try to avoid hacking in C as much as I can ;)). And the other way round, that python module should be able to call C functions of the wrapper which calls geany functions.
Should a plugin have access to variables, too, or can it do everything with functions?
Jonas
On Sun, 07 Jun 2009 16:48:30 +0200 Jonas Haag jonas@jonashaag.de wrote:
Am 06.06.2009 13:52, schrieb Nick Treleaven:
It's a bit complicated. Geany doesn't have a shared library for plugins to link against, instead, Geany sets symbols like geany_functions in each plugin before initialization. Plugins use generated macros to call Geany functions.
So this is like "I create a plugin with C functions in it, register that plugin and geany calls that functions"?
Yes.
I planned to write a wrapper in C that calls functions of a python module which handles all the other stuff (I'll try to avoid hacking in C as much as I can ;)). And the other way round, that python module should be able to call C functions of the wrapper which calls geany functions.
Yes, but I guess you would need one C plugin wrapper per python plugin to wrap the plugin symbols that Geany sets.
Should a plugin have access to variables, too, or can it do everything with functions?
See: http://www.geany.org/manual/reference/howto.html
Regards, Nick
Am 08.06.2009 13:06, schrieb Nick Treleaven:
Yes, but I guess you would need one C plugin wrapper per python plugin to wrap the plugin symbols that Geany sets.
Oh, well - you might be right. Do you think it's possible to handle more than one plugin in one C file/module? How is this done with the lua interface?
I already read this, thanks.
Regards, Jonas
On Mon, 08 Jun 2009 14:18:40 +0200 Jonas Haag jonas@jonashaag.de wrote:
Yes, but I guess you would need one C plugin wrapper per python plugin to wrap the plugin symbols that Geany sets.
Oh, well - you might be right. Do you think it's possible to handle more than one plugin in one C file/module?
I don't think we want to support that.
How is this done with the lua interface?
You're probably thinking of the Lua Scripting Plugin, which is not an interface. You can try it from geany-plugins SVN if you want.
I already read this, thanks.
OK, well that link and the original link shows geany variables - I think plugins would need to access at least one of these.
Regards, Nick
On Mon, 8 Jun 2009 13:40:44 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
Yes, but I guess you would need one C plugin wrapper per python plugin to wrap the plugin symbols that Geany sets.
Oh, well - you might be right. Do you think it's possible to handle more than one plugin in one C file/module?
I don't think we want to support that.
Having thought a bit more, perhaps that would be necessary for proper Python plugins. But it would have to be an elegant and small impact change to plugins.c. It would be interesting to see how other projects do this.
How is this done with the lua interface?
You're probably thinking of the Lua Scripting Plugin, which is not an interface. You can try it from geany-plugins SVN if you want.
Basically the GeanyLua plugin wraps some Geany API functions and exposes these to Lua scripts. The scripts are run when a menu item is clicked, or a script is run in response to an event.
Regards, Nick
Am 10.06.2009 17:33, schrieb Nick Treleaven:
Basically the GeanyLua plugin wraps some Geany API functions and exposes these to Lua scripts. The scripts are run when a menu item is clicked, or a script is run in response to an event.
I think that's the right thing to do, but I want - if possible? - to make those plugins work without being started and controled from within geany but from outside. But, wait a minute, doing things this would make the python plugins not be *real* plugins (because they are not registered by geany and so on)...
I think I will try to get some basic working python wrapper within the next week(s) - I'll see whats possible and whats not ;-)
Regards, Jonas
I started on something similar myself a while back, for Geany 0.16, but ran out of time. The code is here:
https://code.edge.launchpad.net/~mars/+junk/geany-python-bindings
You can grab a copy of the code using bzr:
bzr branch lp:~mars/+junk/geany-python-bindings
And if you just want to browse it on the web:
http://bazaar.launchpad.net/~mars/+junk/geany-python-bindings/files
The plan was to write a Python interpreter started from within Geany, create a Python module wrapping the Geany data structures and functions, and use PyGTK to interact with the graphical components. This is a similar approach to the Gedit Python bindings - PyGTK means you can use Glade for your plugins, which makes plugin development much faster.
The stuff I got stuck on seemed pretty trivial, because I was using the branch to learn Python binding generation as well as practicing some C programming (it's been a few years). The plugin successfully starts a Python interpreter inside of Geany, the waf build scripts work, it can load pure-Python Geany Plugin modules from the disk, etc. etc. I started wrapping the GeanyApp object into it's Python equivalent, but couldn't get the Python class to work. Someone with actual experience writing C Extensions could probably tell what's wrong in a flash.
Of course, the plugin API has changed in 0.17, but this wrapper is so slim at the moment that any updates should be trivial. I considered automatic code generation, but left that for a later pass (geany-lua does code generation using hand-coded interface files and some code extraction, and the Gedit Python bindings are entirely generated) The new Geany plugin interface definition files should make writing language plugins *much* easier than before. Combine that with the Scintilla IDL files and you are flying.
BTW, there is one big problem with the Geany plugin API as of 0.16: Plugins (like Python bindings) can't register other plugins - put another way, a there is no plugin registration API published via the plugin API. With the geany plugin registration API being wrapped in Python, I could easily write pure-Python Geany plugins. Lacking that, I had to come up with my own Python plugin registration.
If anyone wants to hack away on the code, please feel free to do so. I would love to see Python bindings become a reality. They are the one missing killer feature in Geany for me.
Mars
Hi, Sounds interesting.
BTW I don't know anything much about language bindings other than C, just thought I'd ask:
On Thu, 11 Jun 2009 10:00:11 -0400 Mars mfogels@gmail.com wrote:
Of course, the plugin API has changed in 0.17, but this wrapper is so slim at the moment that any updates should be trivial. I considered automatic code generation, but left that for a later pass (geany-lua does code generation using hand-coded interface files and some code
Does it? I assumed it was all hand-coded.
extraction, and the Gedit Python bindings are entirely generated) The new Geany plugin interface definition files should make writing
Not sure what you mean here - are these files you've made?
language plugins *much* easier than before. Combine that with the Scintilla IDL files and you are flying.
BTW, there is one big problem with the Geany plugin API as of 0.16: Plugins (like Python bindings) can't register other plugins - put another way, a there is no plugin registration API published via the plugin API. With the geany plugin registration API being wrapped in Python, I could easily write pure-Python Geany plugins. Lacking that, I had to come up with my own Python plugin registration.
Let us know if you have ideas on how to modify Geany's src/plugins.c, I'm having trouble imagining how it should be done. But don't start working on anything until it's discussed first.
Regards, Nick
Am 11.06.2009 16:00, schrieb Mars:
BTW, there is one big problem with the Geany plugin API as of 0.16: Plugins (like Python bindings) can't register other plugins - put another way, a there is no plugin registration API published via the plugin API. With the geany plugin registration API being wrapped in Python, I could easily write pure-Python Geany plugins. Lacking that, I had to come up with my own Python plugin registration.
+1
I think additionally to the plugin API there should be some interface API which has more privileges (like registering and running other plugins).
As this would be probably difficult to implement I propose to add the possibillity to register a plugin as an "interface" (e.g. to another language). Having a Python interface, users could put their *.py-files in the geany plugins directory and geany passes them to that Python interface. There would be several advantages using such system:
* Plugins offering APIs to other languages wouldn't have to implement a registration API (or, at least, not the whole stuff) * Geany could register the plugins itself (I dunno wether it's important for the plugin system which plugin did what)
I thought about something like this: If a *.py (or *.whatever) file in the plugin directories is found, geany passes that file (path) to the according interface plugin, which returns the meta information (like required API version and stuff) to geany. Whenever geany would call a function of that Python plugin, it passes all the information to the interface plugin which acts as a man-in-the-middle (calls the function in the Python plugin and returns the return-values to geany, if there are any). The same way, Python plugin calls geany API functions: Passes the information to the interface handler, the interface handler acts as man-in-the-middle.
I'm aware of the fact that this would take some effort to implement but I cannot see any other way to do registration of 3rd-party-language plugins right now.
Regards, Jonas
On Fri, 12 Jun 2009 13:06:55 +0200 Jonas Haag jonas@jonashaag.de wrote:
I think additionally to the plugin API there should be some interface API which has more privileges (like registering and running other plugins).
As this would be probably difficult to implement I propose to add the possibillity to register a plugin as an "interface" (e.g. to another language). Having a Python interface, users could put their *.py-files in the geany plugins directory and geany passes them to that Python interface. There would be several advantages using such system:
- Plugins offering APIs to other languages wouldn't have to implement a registration API (or, at least, not the whole stuff)
- Geany could register the plugins itself (I dunno wether it's important for the plugin system which plugin did what)
I thought about something like this: If a *.py (or *.whatever) file in the plugin directories is found, geany passes that file (path) to the according interface plugin, which returns the meta information (like required API version and stuff) to geany. Whenever geany would call a function of that Python plugin, it passes all the information to the interface plugin which acts as a man-in-the-middle (calls the function in the Python plugin and returns the return-values to geany, if there are any). The same way, Python plugin calls geany API functions: Passes the information to the interface handler, the interface handler acts as man-in-the-middle.
Personally I'd prefer Geany to just do the minimum, have some way of registering plugin-like objects from within a C plugin.
The way Geany interfaces with C plugins is by looking up symbols in it by a text string. So if we modified this to also be able to call a function in the C plugin, perhaps that function could handle looking up e.g. Python symbols in a script by name.
Regards, Nick
Am 12.06.2009 13:25, schrieb Nick Treleaven: So if we modified this to also be able to call a
function in the C plugin, perhaps that function could handle looking up e.g. Python symbols in a script by name.
Well, this doesn't solve the registration problem, does it?
There's another way to make every Python plugin being registered individually: Every python plugin uses an own .so C module. But that's not a nice thing to have...
On Fri, 12 Jun 2009 13:42:41 +0200 Jonas Haag jonas@jonashaag.de wrote:
Am 12.06.2009 13:25, schrieb Nick Treleaven: So if we modified this to also be able to call a
function in the C plugin, perhaps that function could handle looking up e.g. Python symbols in a script by name.
Well, this doesn't solve the registration problem, does it?
We would have a function to create a plugin-like object that the C plugin could call, but Geany would still need the lookup function to resolve symbols.
One problem with this approach is that python plugins would only be available after the PythonPlugins C plugin was loaded. IMO this might be OK, or we could make Geany always load it if present.
Regards, Nick
On Fri, 12 Jun 2009 13:08:10 +0100, Nick wrote:
On Fri, 12 Jun 2009 13:42:41 +0200 Jonas Haag jonas@jonashaag.de wrote:
Am 12.06.2009 13:25, schrieb Nick Treleaven: So if we modified this to also be able to call a
function in the C plugin, perhaps that function could handle looking up e.g. Python symbols in a script by name.
Well, this doesn't solve the registration problem, does it?
We would have a function to create a plugin-like object that the C plugin could call, but Geany would still need the lookup function to resolve symbols.
One problem with this approach is that python plugins would only be available after the PythonPlugins C plugin was loaded. IMO this might be OK, or we could make Geany always load it if present.
Sounds OK to me.
Alternatively, maybe some kind of proxy plugin could do the trick: this plugin is loaded by Geany as any other plugin, it provides the necessary symbols Geany expects, and then this plugin provides some interface to various real Python plugins by exporting the Geany API in Python and so this plugin acts as some kind of proxy between Geany and the Python plugins.
Maybe I'm missing something, it's late and I don't know Python nor its bindings to C, so, might be I'm just dreaming :).
Regards, Enrico
Am 15.06.2009 00:02, schrieb Enrico Tröger:
Alternatively, maybe some kind of proxy plugin could do the trick: this plugin is loaded by Geany as any other plugin, it provides the necessary symbols Geany expects, and then this plugin provides some interface to various real Python plugins by exporting the Geany API in Python and so this plugin acts as some kind of proxy between Geany and the Python plugins.
But using this (which would be the easiest way to implement the interface) geany wouldn't know about Python plugins (Python plugins registered at that "proxy" plugin).
On Mon, 15 Jun 2009 14:25:40 +0200, Jonas wrote:
Am 15.06.2009 00:02, schrieb Enrico Tröger:
Alternatively, maybe some kind of proxy plugin could do the trick: this plugin is loaded by Geany as any other plugin, it provides the necessary symbols Geany expects, and then this plugin provides some interface to various real Python plugins by exporting the Geany API in Python and so this plugin acts as some kind of proxy between Geany and the Python plugins.
But using this (which would be the easiest way to implement the interface) geany wouldn't know about Python plugins (Python plugins registered at that "proxy" plugin).
Yo, obviously. I'm not sure how we could get Geany to recognise Python plugins in the first place. I think to get something like this working, we would need to have the whole Python bindings stuff in Geany itself and then we will run into the dependency problem again. If it is the only way at all, it would be ok but as long as it can be avoided, it should, IMO.
But again, I don't know much about this all, just wanted to throw in my 2cents :).
Regards, Enrico
On Sat, 06 Jun 2009 13:31:15 +0200 Jonas Haag jonas@jonashaag.de wrote:
I'm now hacking python for about two to three years and I'm willing to wrap that plugin api to python. Browsing the geany site I noticed that you want such an api as well, so my question is: Are there any special plans for that interface? Or shall I just take the C api and wrap it?
Also, I forgot to mention this has been discussed before:
http://search.gmane.org/?query=python+plugin&group=gmane.editors.geany.g...
Regards, Nick