cc_tools_qt
Common Environment for Protocol Analysis.
|
The cc_tools_qt allows one plugin to influence the configuration of another. The configuration exchange is done via QVariantMap data type and it's up to the plugins to interpret the values stored in the map.
The plugin class is expected to extend the cc_tools_qt::ToolsPlugin and override the applyInterPluginConfigImpl() member function.
In most cases the plugin configuration is handled inside the class extending the socket, filter, or protocol, then such class can override its applyInterPluginConfigImpl() member function while the plugin's applyInterPluginConfigImpl() one can redirect the request.
The plugin class can invoke inheirted reportInterPluginConfig() member function to report populated inter-plugin configuration.
In case the inter-plugin configuration event is initiated inside the class extending the socket, filter, or protocol, then such class can use inherited cc_tools_qt::ToolsSocket::reportInterPluginConfig() member function. The plugin class will connect the signals automatically and emit its own sigInterPluginConfigReport().
HOWEVER, depending on the implementation of the actual plugin, the socket, filter, or protocol objects may be created before the the cc_tools_qt::ToolsPlugin calls appropriate createSocketImpl(), createFilterImpl(), or createProtocolImpl() to get hold on the appropriate object, and may require an ability to still initiate inter-plugin configuration. In such case the the actual plugin is expected to explicitly connect appropriate signal:
Note that the automatic connection of the cc_tools_qt::ToolsSocket::sigInterPluginConfigReport, cc_tools_qt::ToolsFilter::sigInterPluginConfigReport, cc_tools_qt::ToolsProtocol::sigInterPluginConfigReport signals to the cc_tools_qt::ToolsPlugin::sigInterPluginConfigReport signal mentioned earlier happens ONLY when the deriving plugin class does NOT perform such a connection (to avoid duplication).