Closed mzieg closed 11 months ago
I hadn't thought some of this through...we may need the ability for auto-load plugins to wait until a spectrometer has connected, if the plugin wants to do anything "per-spectrometer" during get_configuration (i.e. during connection). Kludging around this in the plugin for now...
we may need the ability for auto-load plugins to wait until a spectrometer has connected, if the plugin wants to do anything "per-spectrometer" during get_configuration
This would be a good opportunity to smarten up our plugin event functions.
What we have:
get_configuration
: used to build user interface, happens after plugin enable and spectrometer connect (which-ever happens latest)process_request
: used to process one tick of plugin logic, happens after post-processing (a rate of once per spectral acquisition)At some point we had a different init-time event, connect
that I wanted to remove. I'm pretty sure that event corresponded to the Connect checkbox in Enlighten. Part of why I wanted to remove it was to reduce the need for multiple checkboxes for plugins, and partially was because Connect was changed to reload plugins, which should happen opaquely to the internal program. Overall it was confusing to have two very similar event functions.
get_configuration and process_request is similar to a synchronous event-driven model used in game design, robotics, computer vision, etc. In those cases the functions tend to be called setup and update, or init and draw, or start and loop, etc.
In order to satisfy situations where spectrometers are plugged or unplugged during plugin time, where there may be multiple spectrometers, etc we can borrow more event-driven mentality. The names of the functions don't matter so much as what event triggers them and what they are used for.
on_gui_init
: used to build user interface, happens on plugin enable (regardless of if spec is connected)on_spectrometer_connect(spec)
: used to initialize spec, happens on spec connection, has the specific spec passed in on_gui_update
: used for gui logic or graph annotations, happens once per frame (regardless of if spec is connected)on_spectral_acquisition(spec)
: used for spectral processing, happens once per spectral acqusition.(on_gui_update would have been useful for maintaining the relationship between Count and x_0, x_1, ..., in LocalBaseline for exaple)
These can be added at any time while maintaining backwards compatibility.
This should close #283 ?
Adding features to simplify deployment in "kiosk" mode with undesired features disabled via plugin.