Deprecate Plugin Dependencies

[mzieg]

• support 'events' in functional plugins
• remove plugin 'dependencies' (not needed with access to the Controller)
• hide plugin field frame if no fields

[samiebee43]

Overall I really like the direction this is going. I'm glad we can deprecate plugin_dependencies.

The only thing I disagree with is the inclusion of an event queue. I rather we dispatch events as soon as we are aware of them, implying a user-space requirement that event handlers take no longer than 17ms to return.

[mzieg]

The only thing I disagree with is the inclusion of an event queue. I rather we dispatch events as soon as we are aware of them, implying a user-space requirement that event handlers take no longer than 17ms to return.

The only real event queue in the plugin architecture is the out-going EnlightenPluginResponse.signals array (basically used by Prod.BurnIn) which I agree is clunky...I just haven't figured out the right way to dispatch closures to the Qt GUI thread from inside PluginWorker's threading.Thread.

EnlightenPluginConfiguration.events isn't really a queue, it's meant to hold callback methods when various things happen inside ENLIGHTEN that a plugin might need to know about.

Now that I think about it, since plugins now have access to the Controller and all BusinessObjects, they can simply "register" for the events they care about directly, and we no longer need separate handling of those.

I'll take a look at deprecating events next, in a separate branch.

Note to self: it looks like EnlightenPluginConfiguration.events was a dict, but EnlightenPluginBase._events is a list...confusing.

[samiebee43]

I wrote about how I think plugins should deal with events in the future here: https://github.com/WasatchPhotonics/ENLIGHTEN/wiki/EFPlugins#user-concept

The main idea is that the user implements functions with special names based on the event they handle. The plugin system has all of those names hardcoded. When an event happens, say on_gui, the plugin system will check if the plugin has implemented such a function, and if so it'll call it immediately.

[mzieg]

Hi Samie, any other changes required for this to go into 4.1.0? The ability to use PluginController's existing event callbacks from functional plugins will be useful.