Hi, As using pointers to call plugin API functions is a bit ugly, I've been planning on writing a wrapper shared library. But perhaps that is unnecessary, perhaps macros would do instead:
#define plugin_add_toolbar_item \ p_plugin->add_toolbar_item
Are there any problems with this approach?
The attached script genapi.py currently does this for all API functions, put it in the src/ folder:
$ cd src $ python genapi.py Generated geanyfunctions.h
Regards, Nick
On Mon, 24 Nov 2008 17:20:51 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
As using pointers to call plugin API functions is a bit ugly, I've been planning on writing a wrapper shared library. But perhaps that is unnecessary, perhaps macros would do instead:
#define plugin_add_toolbar_item \ p_plugin->add_toolbar_item
Are there any problems with this approach?
The attached script genapi.py currently does this for all API
I know that normally we should avoid macros, but I think for function names this should be OK, I can't think of any good reason why there would be name conflicts.
geanyfunctions.h would have to be included after anything like utils.h. But I think we should add a single header include for plugins, so this would ensure headers were included in the right order. A single header include is probably good anyway in case we want to move declarations or rename any source files.
I'd like to add this to SVN, maybe somehow deprecating pluginmacros.h, but not removing it for a while. In future, genapi.py could add the geanyfunctions-> prefix and we could remove pluginmacros.h.
Regards, Nick
On Thu, 27 Nov 2008 18:35:39 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Mon, 24 Nov 2008 17:20:51 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
As using pointers to call plugin API functions is a bit ugly, I've been planning on writing a wrapper shared library. But perhaps that is unnecessary, perhaps macros would do instead:
#define plugin_add_toolbar_item \ p_plugin->add_toolbar_item
Are there any problems with this approach?
The attached script genapi.py currently does this for all API
I know that normally we should avoid macros, but I think for function names this should be OK, I can't think of any good reason why there would be name conflicts.
geanyfunctions.h would have to be included after anything like utils.h. But I think we should add a single header include for plugins, so this would ensure headers were included in the right order. A single header include is probably good anyway in case we want to move declarations or rename any source files.
I'd like to add this to SVN, maybe somehow deprecating pluginmacros.h, but not removing it for a while. In future, genapi.py could add the geanyfunctions-> prefix and we could remove pluginmacros.h.
I'm fine with this, go ahead. It'd be much better to have plugin_add_toolbar_item than p_plugin->add_toolbar_item even though we will get this by macros :).
It makes the code more readable, more easy to write and then the function names match with the API docs.
Regards, Enrico
On Thu, 27 Nov 2008 18:35:39 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
I'd like to add this to SVN, maybe somehow deprecating pluginmacros.h, but not removing it for a while. In future, genapi.py could add the geanyfunctions-> prefix and we could remove pluginmacros.h.
I've added geanyfunctions.h to SVN, but I think we could make pluginmacros.h deprecated now, with a few small changes:
* Move the geany macro to plugindata.h. * Add accessor functions for documents_array and filetypes_array.
Then geanyfunctions.h could use the full geany_functions->p_prefix-> syntax, which would require that pluginmacros.h is not included.
I think updating plugins to use geanyfunctions.h would be pretty straightforward; for most plugins probably just changing the header include and a regex replace of function pointer syntax. Anyway I'll add an announcement when the new geanyfunctions.h code is completely ready for use.
Regards, Nick
On Wed, 3 Dec 2008 12:56:04 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 27 Nov 2008 18:35:39 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
I'd like to add this to SVN, maybe somehow deprecating pluginmacros.h, but not removing it for a while. In future, genapi.py could add the geanyfunctions-> prefix and we could remove pluginmacros.h.
I've added geanyfunctions.h to SVN, but I think we could make pluginmacros.h deprecated now, with a few small changes:
- Move the geany macro to plugindata.h.
- Add accessor functions for documents_array and filetypes_array.
Then geanyfunctions.h could use the full geany_functions->p_prefix-> syntax, which would require that pluginmacros.h is not included.
I think updating plugins to use geanyfunctions.h would be pretty straightforward; for most plugins probably just changing the header include and a regex replace of function pointer syntax. Anyway I'll add an announcement when the new geanyfunctions.h code is completely ready for use.
Cool, sounds like a plan.
Regards, Enrico
On Wed, 3 Dec 2008 16:31:55 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 3 Dec 2008 12:56:04 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 27 Nov 2008 18:35:39 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
I'd like to add this to SVN, maybe somehow deprecating pluginmacros.h, but not removing it for a while. In future, genapi.py could add the geanyfunctions-> prefix and we could remove pluginmacros.h.
I've added geanyfunctions.h to SVN, but I think we could make pluginmacros.h deprecated now, with a few small changes:
- Move the geany macro to plugindata.h.
- Add accessor functions for documents_array and filetypes_array.
Then geanyfunctions.h could use the full geany_functions->p_prefix-> syntax, which would require that pluginmacros.h is not included.
I think updating plugins to use geanyfunctions.h would be pretty straightforward; for most plugins probably just changing the header include and a regex replace of function pointer syntax. Anyway I'll add an announcement when the new geanyfunctions.h code is completely ready for use.
Cool, sounds like a plan.
Just a thought: Would it be logical to update all plugins inside geany-plugins subversion in one rush after update is in place?
Cheers, Frank
On Wed, 3 Dec 2008 19:22:07 +0100 Frank Lanitz frank@frank.uvena.de wrote:
Just a thought: Would it be logical to update all plugins inside geany-plugins subversion in one rush after update is in place?
Well, I don't think we should update plugins without agreement from the maintainer. But I don't mind updating some plugins or making one big patch with all the changes.
(Just to mention, these changes don't break the API, just deprecate some of it).
Regards, Nick