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.