WIP [ENH,MAINT] MNE Scan - Plugin/Scene/GUI separation #887
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A quick overview of the current state of plugins before we talk about this PR.
What is a Plugin in MNE-CPP?
A plugin is a library that is loaded at runtime that follows a set API. Plugins inherit from an abstract base class defined in the application library. Plugins can be recompiled separatley from the main aplication and, as long as the main application and the plugin are using the same abstract base-class api, there should be no issues.
Plugins are currently all loaded in at once soon after the main application starts execution. Plugins are loaded in based only on their .dll/.a/.o files.
What is a plugin in MNE Scan?
In MNE Scan, a plugin is a subclass of either AbstactSensor or AbstractAlgorithm, both of which are subclasses of AbstractPlugin. AbstractPlugin is a subclass of QThread, making it so that plugins are threads.
Plugins have inputs and outputs that can asynchronously send and receive data.Plugins are added to the "scene" and can be connected to each other based on matching inputs and ouputs.
AbstractSenor-derived plugins are limited to one intance per "scene", and typically only have ouputs. AbstractAlgorithm plugins have no limit in their number of instances, and typically have either both an input and an output, or just an input.
Plugins are very closely linked to their GUI elements, and their APIs are responsible for providing the main application with a lot of gui elements and information. Currently the only gui elements that are abstracted away from the plugins are the plugin startup widgets (which are typically implemented as a separate class but still returned by the plugin), and the data viewers (which get instantiated by the main application based on the type of data being outputed).
Plugins currently only do work by being a link in the overall plugin pipeline, and only affect other plugins by either recieving/passing blocks of data, or by modifying some shared value in that same data.
With all that being said:
This PR aims to decouple the GUI, plugins, and the plugin scene, such that it can allow us to build plugins that provide functionality outside just the "scene" pipeine context. The API and organization is by no means final and I'd really appreciate input.