Exposure Updates: more regular refresh + a cache

[ianhi]

Otherwise the displayed value may not match up with the true exposure

[codecov[bot]]

Codecov Report

Merging #79 (114ad64) into main (3ad1ed0) will increase coverage by 0.96%. The diff coverage is 88.63%.

@@            Coverage Diff             @@
##             main      #79      +/-   ##
==========================================
+ Coverage   60.92%   61.88%   +0.96%     
==========================================
  Files          11       11              
  Lines        1492     1535      +43     
==========================================
+ Hits          909      950      +41     
- Misses        583      585       +2     

Impacted Files	Coverage Δ
micromanager_gui/_util.py	63.70% <86.11%> (+9.16%)	:arrow_up:
micromanager_gui/main_window.py	70.87% <100.00%> (+1.24%)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 3ad1ed0...114ad64. Read the comment docs.

[ianhi]

while looking at this I noticed that we aren't doing the kind thing of remembering what the user set the exposure to on a per channel basis. This is a behavior I think MM gets really right and would like to have the ability to replicate here.

So i added a new ExposureCache object that the main window can use to remember what the user last set the exposure to for any given channel.

In the case where the user set the exposure in the config group (something they shouldn't do) it will not override with the most recent value. I could see this going either way but I think that sticking to config value is the safest option.

Before: Only one exposure value - applied to all channels

After:

[ianhi]

Unfortunately I'm really struggling to get the tests to pass. If I execute the test manually via the UI it all behaves as expected, but I can't seem to get it to pass on [remote] only on [local] so I suspect something is wonky with signal timing, but I can't pin it down.

[ianhi]

Final thought: This may be another case of something that should live in pymmcore-plus but again never fully sure and it was easier to test out here first.

[tlambert03]

while looking at this I noticed that we aren't doing the kind thing of remembering what the user set the exposure to on a per channel basis. This is a behavior I think MM gets really right and would like to have the ability to replicate here.

yep agreed, good feature. Did you happen to check how MM implements this?

[ianhi]

Start here:

https://github.com/micro-manager/micro-manager/blob/225a28c69a0a04305f85ca580b5722a2d0c6f0de/mmstudio/src/main/java/org/micromanager/internal/dialogs/AcqControlDlg.java#L1020-L1038

Uses these get/set channel exposure times https://github.com/micro-manager/micro-manager/blob/225a28c69a0a04305f85ca580b5722a2d0c6f0de/mmstudio/src/main/java/org/micromanager/internal/DefaultApplication.java#L134-L166

which do caching via these functions: https://github.com/micro-manager/micro-manager/blob/225a28c69a0a04305f85ca580b5722a2d0c6f0de/mmstudio/src/main/java/org/micromanager/internal/DefaultApplication.java#L161-L172

I think the one difference in behavior is that if you have a channel setting that includes exposure as one of the properties and you:

1. Go to a channel (DAPI)
2. Manually set the exposure to a value different than the config group
3. switch channels
4. back to DAPI

Then the exposure will be what you last set it to, and the channel config drop down menu will go blank the microscope state no longer exactly matches the config group. Whereas here the config group setting will be restored. I can see arguments for both ways here and I think that this is something that should ultimately be togggleable via a settings file.

[ianhi]

@tlambert03 bump here

[ianhi]

Needs a rebase and also putting off for #111

[tlambert03]

@ianhi, can you make a new PR with just the bit that prevents the displayed value from matching the actual value? then do cache in a different pr?

[tlambert03]

@ianhi, is this still something that you want to work on, or should we close?