Imswitch integration

[henrypinkard]

@jacopoabramo @nornil @kasasxav

I'm making this issue to have a centralized place for discussion about the integration of ExEngine into Imswitch. The documentation is now live and mostly complete.

I think the first steps we discussed were:

1. Adding the imswitch managers as a device backend once they are split into their own package. There's now a guide on how to do this.

2. Building a new master controller on top of ExEngine, and using the notification API to update the GUI from hardware as needed.

I know there were some things to take care of before this could begin. When you do get to it, feel free to ping me if you have more question

[jacopoabramo]

On the side of ImSwitch the imperative steps to make an easy integration of ExEngine, at least after my personal analysis, are the following:

• finishing the integration of the latest PRs/unofficially declared PRs; this will bring us in the condition of freezing new PRs until we are capable of fully integrating the plugin system and laying the ground basis for implementing the ExEngine in the master controller;
  • there are currently 3 open PRs; the ones that will be surely committed to the master branch are:
    • Adding OPT integration as widget/controller
    • Release of version 2.1.0, which still requires spawning a new PR with some changes from @beniroquai as he'll be adding the finishing touches on the implementation of some of his widgets/controllers
• adjusting the existing plugin functionalities, specifically porting the code currently relevant to integrating plugins into an ImSwitch setup into ImTools (the repo is currently private but I'll make it public once I'm sure of the results);
  • we need to setup a system capable of integrating plugins at different levels, both as module, plugin bundles (a group of multiple types of combined widgets) and single plugins; this is challenging on its own;
  • lots of base controller classes are still in the core repo of ImSwitch, I want to move them to ImTools as well but I will need to discuss with @kasasxav a little bit further about this;
  • an existing skeleton of integrating managers as plugins currently exists in the dev branch from which version 2.1.0 will spawn, implemented by @beniroquai; I want to use his design and improve upon it
• porting the existing widgets/controllers into new repositories such as to treat them as plugins for ImSwitch;
  • we need to ensure that all existing widgets/controllers/managers are retro-compatible, in order to minimize the transition effort if people want to use the new ImSwitch version with old plugins; this will also allow a more efficient licensing strategy as I discussed with Xavier already;
  • we currently have the following sets of possible "repositories":
    • Plugin bundle: common plugins (developed by @kasasxav; some baseline controller/widgets usable by all users i.e. FFT computation, focus lock system handling, hardware controllers, scanning etc.);
      • I'm imagining that these can be shipped together with ImSwitch when installing them since they're fairly common but we can devise a strategy for that later on;
    • Plugin bundle: plugins for controlling UC2-specific hardware and/or microscopes (developed by @beniroquai);
    • Plugin bundle: Super-resolution plugins (developed by @kasasxav; these are specific to super resolution microscopes and they would need a non-BSD3 license as stated by Xavier);

After that we should be in a golden state where we can integrate the functionalities of the ExEngine and create new template classes to use in integration with the engine itself (if necessary, but it should not be critical).

I could potentially skip the first steps of integrating the latest PRs but I'm scared of the mess we would be in.

[henrypinkard]

What's this exactly? Is this spam?

Seems like phishing. I blocked them and deleted the comments so no one accidentally clicks on it

[henrypinkard]

It sounds like a good plan! Let me know when you need my help

[jacopoabramo]

To be clear, my plan was to build a singleton engine object to use inside the master controller. In the end what I imagine is that the engine and its notification API will go inside the ImSwitch framework to be used by developers for their controller implementation. It will be considered the "preferred" way, while leaving the old framework still existing. After some time I will probably make it deprecated and remove it entirely

[henrypinkard]

Yeah that makes sense. And the engine is designed as a singleton so that should be straightforward.