a wxRaven Plugin is quite simple to create and flexible enough to allow developers to make their own design choices.

As a strict minimum, a plugin need ONE class to work : the main plugin class object for the plugin declaration.

For convenience, this main class is used as a plugin-proxy caller meaning that any high level interactions between plugins must be done by calling functions in this super-class.

This works as the same way than if the plugin want to interact with wxRaven application.

The logical process and execution of those high level calls can be then described and executed according to your design choices but wxRaven provides some instruments as well.

    • Plugins Views : a plugin can contain one or more views in it to enable interaction with end-user if needed. the definition of a view is standardized so it can be manged by the wxRaven View Manager and the overall HMI management.

    • Plugins Settings Panels : a simple mechanism to allow you to design the settings internal-panel and let you manage settings for your plugin through the built-in mechanism.
      As side note, a plugin can have settings without necessarily having to design a setting panel for them, but in that case the settings are only editable in the config file or through console commands.

    • Plugin Jobs : Jobs are one way to execute long-processing tasks in the background or tasks that otherwise would stuck the HMI if executed in the main application thread.
      It is the recommended way to execute simple blockchain interactions and end-user use-cases because of job re-usability and cross plugin interaction.

      But for any specific reason or for any non-standard plugin, the developer can choose to use it's own thread management mechanism as long those big tasks are not executed in the main thread. 

Created with the Personal Edition of HelpNDoc: Free Kindle producer