Should GUI functionality be constrained to the configuration nodes?

[bparks13]

While working on #78, we started off attempting to abstract the hardware and consolidate functionality to the node that makes the most sense; in our case, using the Rhs2116StimulusTrigger node as the node that opens up a GUI which allows the user to configure a stimulus waveform even if the workflow is not running, and also to allow them to change it while running.

However, with recent additions (e.g., Probe Interface channel configurations), there is now a need to configure the channel configuration at the headstage level (ConfigureHeadstageRhs2116), since this is a headstage property and not a device property. This is potentially confusing and could cause issues long-term if users are not instantiating the channel mapping correctly via the headstage GUI before opening the stimulus sequence GUI.

Prior discussions have brought up the possibility of the ConfigureHeadstage* nodes containing tabs for each device, and allowing the user to change all devices under the specific headstage in one place.

The question here is; should the GUI for changing configurations only be allowed at the level of the headstage / device configuration? Previously there was a thought that these configurations could happen at either level, but it might be best to constrain it to only occur along the Configure node pipeline for clarity.

This change would still allow some specific properties (i.e., Rhs2116StimulusSequence, maybe Rhs2116AnalogLowCutoff?) to be modifiable during runtime, but this would be accomplished through externalizing the specific property and manipulating it that way. This brings up another possibility of adding specific logic nodes to modify these externalized properties, but that discussion can probably wait for another day.

[bparks13]

Another question that becomes relevant with this discussion is how to handle some of the run-time changes; should the configuration be a static property that is reset every time the workflow is restarted? That is to say, if there is a specific stimulus sequence programmed at the headstage level, but then there are modifications to the sequence that are performed during run-time, should these modifications be back-propagated to the configuration node to be used the next time the workflow is run?