Wishlist for ImSwitch

[beniroquai]

A loose list of things that may be useful for ImSwitch in the future - we can start a discussion for this too.
Feel free to add random thoughts; We can transfer them to discussions, too.

I start:

• Plugin system for widgets / potentially hardware too
• Integration/Linking between micromanager and imswitch
• Better Installer + Updater to have a single button click experience
• updated documentation
• graphical setup configurator

[jacopoabramo]

I think that we should start using the GitHub project session and start putting all these into a wishlist.

[beniroquai]

Sounds great! Do you want to start organizing this?

[ondrejstranik]

Adding to the wishlist:

• in the json configuration file extend the parameter setting also for widget

[jacopoabramo]

Adding to the wishlist:

• in the json configuration file extend the parameter setting also for widget

Could you elaborate more on this? You mean having parameters for the widget similar to what one would have for a device?

[kasasxav]

My wish would be to have more tests before adding new features, and also some systems for developing tests when there are new features added. For example mockers for all devices and testing either with the physical device or with the mock.

[kasasxav]

I guess @ondrejstranik means that we could have an attribute called "widgetProperties", for example like we have "managerProperties". It could be inside the section "availableWidgets", one should be able to change that easily in SetupInfo.

[jacopoabramo]

I guess @ondrejstranik means that we could have an attribute called "widgetProperties", for example like we have "managerProperties". It could be inside the section "availableWidgets", one should be able to change that easily in SetupInfo.

I'm not so sure this makes sense; usually widgets are a means for users to provide properties which are then sent to the controller/manager. What would be the use case for implementing it?

[ondrejstranik]

My wish would be to have more tests before adding new features, and also some systems for developing tests when there are new features added. For example mockers for all devices and testing either with the physical device or with the mock.

I strongly agree with this point. Idelally, all devices (type), should have a mocker, which will also define the expected reponses from the real devices (e.g. now the mocker camera even does not allow to set the exposure time).

If we have it then performance of a new devices (Managers) could be done compared with the mocker.

Also new widgets/controllers, could be then tested on virtual mockers.

It could be even more expanded to have a mocker sample. This sample would have some structure, position, emission properties.
The you could virtually image this sample with a mocker camera, move it with a mocker stage, illuminated with a mocker laser, apply a mocker shutter, a project a mocker SLM (spatial light modulator) on it,
Imswitch would be then also kind of a virtual microscope and it would be ideal for a testing.

[ondrejstranik]

Further on a wishlist:
generalised the spatial light modulator device

1. add manager of slms (similar to DetectorsManager). To control more slm simultaneously
2. add general slm manager (now the implementation of slm is bound to a type of slm, which is controll by a projection on a virtual screen)

[ondrejstranik]

Further on a wishlist:

1. be able to disable widgets from other controllers by emitting a signal. Each widget such a functionality.
   The reason for it is e.g. I carry out data acquisition sequence and I do not wont during the acquisition that the user change the exposure time of camera. So I would disable the camera parameters seting widget. After finishing the acquisition I can again emit a signal to enable the widget functionality.

[beniroquai]

I remember there was somebody talking about a "virtual microscope" which would directly address the mocker situation. Did you mention that in one of our converseations @jacopoabramo ?

One more thing for the wish list: integrating ImSwitch into ImJoy-RPC to remote control it and process data on their hypha server system https://slides.imjoy.io/?slides=https://raw.githubusercontent.com/oeway/slides/master/2022/i2k-2022-hypha-introduction.md