[Geany-Devel] Plugin API design question/change proposal
mbrush at xxxxx
Sun May 25 23:10:54 UTC 2014
If nobody's opposed to this, then I'll start working on it shortly. At
worst we'll end up with some new `*private.h` files in the `src`
directory and maybe find some buggy plugins and/or
I'll try to keep the private headers changes separate from the removal
of the `geanyfunctions.h`/function pointer macros stuff, since in theory
they are independent of each other.
On 14-05-20 02:29 AM, Matthew Brush wrote:
> Does anyone know why the plugin API was designed to use a bunch of
> structures containing function pointers, hidden behind macros in
> geanyfunctions.h? I found the commit where this stuff was added
> initially (ie. plugin ABI 2-3) but it doesn't mention why it was done
> like this and I tried to search the mailing list archives but Gmane
> won't let me search and the other mailing list archive doesn't go back
> that far.
> Somebody mentioned it might be because Windows doesn't export symbols by
> default, but it still doesn't explain why this way chosen over
> explicitly exporting the symbols using
> __declspec(dllexport)/G_MODULE_EXPORT which, IIUC, does just this.
> As mentioned in the "Proxy Plugins" thread I'm looking into making the
> headers scanned by GObject-introspection to automate binding the plugin
> API to non-C plugins, but with all of the private stuff and public stuff
> mixed together in public headers, it will be hard to do this.
> Assuming there isn't actually much of a reason for the chosen existing
> function pointer/structure/macro mechanism, is anybody opposed to just
> making the API available in the normal C way where the public functions
> goes in one header that plugins (and core) can use, and one header where
> the private stuff goes, that doesn't get installed?
> Just to see the work involved, I tried to do this with the build,
> document and editor functions. It makes the public/private more
> explicit, removes lots of extra code, makes only one place to update
> when adding new functions to the API, doesn't force plugins to import a
> bunch of private stuff indirectly by #including <geanyplugin.h>, still
> makes the symbols available/exported on Windows, and does it without
> breaking the official (ie. doxygen-commented) parts of the API (but it
> would need an ABI bump). The experimental changes to build, document,
> and editor functions are here in my header-cleanup-private branch, based
> ontop of my "header-cleanup" branch that I have an open PR for:
> What we could do for commonly used existing private stuff:
> (Sorry, I just linked the relevant commits instead of the branch so
> people don't have to figure out which specific ones I'm talking about
> amidst all the other unrelated ones. It's mostly just to give an idea of
> what I'm talking about.)
> I think this would be a fairly big improvement overall and it would
> finally allow us to sort out what's really private and what's really
> public, which will make bindings generated by scanning the headers much
> Some common stuff that wasn't public before (ie. doxygen-commented) but
> that is still used in plugins could be added as "deprecated" to the
> public header or if useful could be properly added with a doxygen
> comment. This will avoid excessive breakage where plugins were using
> private stuff.
> Any opinions, suggestions, reasons about the original design welcome.
> Matthew Brush
> Devel mailing list
> Devel at lists.geany.org
More information about the Devel