GUI improvements

[henrypinkard]

@bls337 I thought it would helpful to keep track of GUI-realted things I run into while testing:

• On the data panel, both the "save images" checkbox and datastore selection (which includes RAM) are present. To me this seems redundant since RAM datastore would be not saving. Or is not saving images related to some kind of hardware test?
• It would be very helpful for testing (and also eventually for users) if the GUI remembered settings between different runs. In particular remembering the saving folder and name would save me a lot of clicking.
• The add and remove channels I assume are supposed to have icons or labels but they are not big enough to display on my screen:

• How should the acq eng callback to the GUI to let it know an acq is finished? Right now the stop acqusition never returns to start acquisition

[bls337]

I fixed the add and remove channels buttons, they are readable now.

[bls337]

The acquisition settings object is saved when the plugin closes, and when the plugin opens the acquisition settings object is loaded and the gui is populated with it's values. Most of the gui controls are being initialized from the acquisition settings, but not all of them are. In the case of the data tab, the gui wasn't being initialized with the acquisition settings and the save path on the Datastore itself was not set correctly. I changed the createDatastore method to take the path as a string, it's now being created at the beginning of the acquisition.

Do we need to close the Datastore at the end of an acquisition? It would be nice to incorporate the freeze method to prevent the Datastore from being modified after an acquisition as well.

[bls337]

I removed the RAM datastore option from the radio button. I don't think there's any reason to have it, it was just left over from throwing things together. I haven't connected that part of the gui to the Datastore yet, it seems like users would want to be able to change between SINGLEPLANE and MULTIPAGE TIFF formats?

[bls337]

I will think about a good solution for the acquisition engine to communicate with the user interface. Maybe having the acquisition engine emit a signal that gui can register to listen to, so the observer pattern, or Google event bus would work.

[henrypinkard]

The acquisition settings object is saved when the plugin closes, and when the plugin opens the acquisition settings object is loaded and the gui is populated with it's values.

Okay good to know. It might worthwhile to have the acquisitions settings save whenever they are changed in addition to when the plugin closes. This would, for example, mean settings aren't lost in case of a crash.

Do we need to close the Datastore at the end of an acquisition? It would be nice to incorporate the freeze method to prevent the Datastore from being modified after an acquisition as well.

Right now its not using the Datastore interface, but rather going into NDTiff directly through its API, but I plan to add datastores shortly and this functionality as well.

seems like users would want to be able to change between SINGLEPLANE and MULTIPAGE TIFF formats?

Were single plane images used in the diSPIM plugin? I know that writing code is much slower than the multipage tiffs, so it may not be worth it to include it

I will think about a good solution for the acquisition engine to communicate with the user interface. Maybe having the acquisition engine emit a signal that gui can register to listen to, so the observer pattern, or Google event bus would work.

Yes, I think that sounds good. The event bus should work, though I have found that code that uses it can be hard to debug. If its just a one or two functions, you might just consider adding API methods to the GUI directly