gs-plugin: Bind initialize/destroy to the GsPlugin lifetime
This is a step towards having a GsPlugin subclass per plugin, which
will allow the vfuncs to be class methods, and avoid a load of dlsym()
calls on every plugin job. It will also allow the C type system to be
used, rather than a load of dynamic function pointer casting in
gs-plugin-loader.c. Finally, it will prevent the perennial issue of
identically-named symbols from multiple modules being conflicting in the
process’ function name space, and being difficult to grep in the source
code.
Signed-off-by: Philip Withnall pwithnall@endlessos.org
This is one step towards reworking the plugin API and threading model. The idea is that each plugin will provide a class derived from GsPlugin, which it can use to store its private date. This replaces GsPluginData, which partially reinvented the GObject private data system.
Plugins will eventually set all their functions (gs_plugin_add_search(), etc., from gs-plugin-vfuncs.h) as vfuncs on the class struct, rather than giving them well-known names which are found using dlsym(). This will prevent plugin function names colliding, and make it possible to type check them.
This branch just eliminates the initialize() and destroy() vfuncs, turning them into my_plugin_init() and my_plugin_{dispose,finalize}() instead. Subsequent branches will update more of the vfuncs.
Most of the commits on this branch make a minimal set of changes to add a new type derived from GsPlugin for each plugin, and convert its initialize() and destroy() vfuncs. This requires a number of the self pointers to be changed around between GsPlugin* and GsPluginAppstream* (for example), and various casts added and removed.
These commits do not need close review, but unfortunately are not mechanically verifiable. Mostly the changes are s/priv->/self-> and replacing gs_plugin_get_data() with accesses to the derived type struct.
Only the first commit and last two commits on the branch need close review.