Hello
evstevemd wrote:I thought before I invade CL sources I should familiarize myself on plugin architecture. i have read a lot of docs on net and i have come to a conclusion that I need
1. plugin interface (API is defined by this class) which is pure abstract with at least getPluginName, loadPlugin and unloadPlugin
Beware, there are 2 notions :
1 - the plugin library interface, which is the C interface of the DLL / so library. This interface provide te capacity of retrieving the plugin class. You'll have the getPlugin function and maybe more (in CL, you have a getPluginInterfaceVersion, which allow to not load a plugin which is not whith the up to date version)
2 - the plugin interface class, which provide the functionnalities you defined : load, unload, ... It's an abstact class which need to be implemented by each plugins. This class will do the job.
evstevemd wrote:2. Plugin manager class that loads plugins and their methods
Right.
evstevemd wrote:3. Plugin that implements interface class
Once again, right
evstevemd wrote:4. host app
right.
I add once again the interface (pure abstract) class which allow to exchange information between the application and the plugins. This class must be implemented in the host app and gives acces to all information that can be shared whith the plugins (GUI to add panes, core datas, ...). In CL, tis class is the same as the one which load the plugins.
evstevemd wrote:How things goes when it comes to wxWidgets?
wxWidgets provide a
wxDynamicLibrary class which load DLL / so library, and call function of this library (getPlugin). After, this is not wxWidgets specific...