Hi all, I've now split up the GeanyApp struct with the new GeanyMainWidgets struct (and renamed or moved a few fields), to allow us to keep the plugin ABI stable without making the code difficult to read/maintain.
For details, see: http://geany.svn.sourceforge.net/geany/?rev=2609&view=rev
I'm hoping we can make all the major API changes (ones that affect most plugins) before the 0.15 release. There are a few more I think are worth doing:
1. Add a plugin_ prefix for plugin symbols like init(), cleanup(), etc. 2. Change the info() plugin function to allow for more PluginInfo fields being added in future. 3. Change the configure() plugin function so that multiple/all plugins can be configured at once from a common dialog. 4. Fix any obvious inconsistencies such as naming - this one is a bit vague ;-)
If anyone has any comments/ideas about how to improve the API (without too much porting needed), let us know.
Regards, Nick
On Thu, 22 May 2008 17:58:35 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
If anyone has any comments/ideas about how to improve the API (without too much porting needed), let us know.
Since API changes require modification of all plugins to compile anyway maybe it is good time do drop deprecated macroses.
On Thu, 22 May 2008 21:43:33 +0300 Yura Siamashka yurand2@gmail.com wrote:
On Thu, 22 May 2008 17:58:35 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
If anyone has any comments/ideas about how to improve the API (without too much porting needed), let us know.
Since API changes require modification of all plugins to compile anyway maybe it is good time do drop deprecated macroses.
Maybe we could drop almost all the pre-0.14 deprecated stuff. The more recent deprecated macros I added to make porting easier. But we should be clear why if we do this - e.g. do the macros cause name conflicts for plugin authors often?
Anyone else have opinions on this?
One reason why I haven't dropped the old function macros yet is because sometime I can imagine having an auto-generated wrapper library for the geany_functions function pointers, so plugins can just write the function name like in the core. Not sure how difficult it would be to auto-generate yet.
Regards, Nick
On Fri, 23 May 2008 12:49:18 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
Maybe we could drop almost all the pre-0.14 deprecated stuff. The more recent deprecated macros I added to make porting easier. But we should be clear why if we do this - e.g. do the macros cause name conflicts for plugin authors often?
I encounter name conflicts few times, it is rare enought to be annoying. But why keep useless garbage since: 1) Every old plugin just have to be modified to compile with new API anyway. 2) Do you know plugins that still use them?
One reason why I haven't dropped the old function macros yet is because sometime I can imagine having an auto-generated wrapper library for the geany_functions function pointers, so plugins can just write the function name like in the core. Not sure how difficult it would be to auto-generate yet.
How these macroses will help with auto-genearating? If some script generate code it should not matter what to generate.
On Fri, 23 May 2008 21:16:33 +0300 Yura Siamashka yurand2@gmail.com wrote:
On Fri, 23 May 2008 12:49:18 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
Maybe we could drop almost all the pre-0.14 deprecated stuff. The more recent deprecated macros I added to make porting easier. But we should be clear why if we do this - e.g. do the macros cause name conflicts for plugin authors often?
I encounter name conflicts few times, it is rare enought to be annoying. But why keep useless garbage since:
- Every old plugin just have to be modified to compile with new API
anyway.
It makes it easier to make plugins compatible with Geany 0.15, less replacements needed.
- Do you know plugins that still use them?
It depends which macros you're talking about, but I assume the old function pointer struct macros. Not off hand, but until last week at least one was using them.
One reason why I haven't dropped the old function macros yet is because sometime I can imagine having an auto-generated wrapper library for the geany_functions function pointers, so plugins can just write the function name like in the core. Not sure how difficult it would be to auto-generate yet.
How these macroses will help with auto-genearating? If some script generate code it should not matter what to generate.
They don't. But plugin authors might have to switch from documents-> to p_document-> to document_. Keeping the original macros might mean only one switch. But probably it's not much work to port anyway.
Regards, Nick
On Thu, 22 May 2008 17:58:35 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
If anyone has any comments/ideas about how to improve the API (without too much porting needed), let us know.
Why app, main_widgets, doc_array, filetypes_array, prefs, project macroses don't have 'p_' prefix like all other do?
On Thu, 22 May 2008 21:51:52 +0300 Yura Siamashka yurand2@gmail.com wrote:
On Thu, 22 May 2008 17:58:35 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
If anyone has any comments/ideas about how to improve the API (without too much porting needed), let us know.
Why app, main_widgets, doc_array, filetypes_array, prefs, project macroses don't have 'p_' prefix like all other do?
Well, the p_ prefix was to avoid conflicts with variable and type names - so mainly to distinguish function struct pointers from variable pointers.
But I think it would be neater to remove (deprecate for now) these macros and instead use a geany macro for all API variable pointers as described in my other post.
Regards, Nick