feat: New ConfigGroupsEditor widget.

[tlambert03]

i still find creating config groups to be a little clunky... playing around with another approach:

see examples/config_groups_editor.py

[codecov]

Codecov Report

Attention: Patch coverage is 82.95218% with 82 lines in your changes missing coverage. Please review.

Project coverage is 86.76%. Comparing base (8aa965d) to head (cd629c7).
Report is 5 commits behind head on main.

Files with missing lines	Patch %	Lines
...mmcore_widgets/config_presets/_unique_name_list.py	70.76%	57 Missing ⚠️
...re_widgets/config_presets/_config_groups_editor.py	92.99%	15 Missing ⚠️
...idgets/device_properties/_device_property_table.py	83.87%	10 Missing ⚠️

❌ Your patch status has failed because the patch coverage (82.95%) is below the target coverage (85.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #307      +/-   ##
==========================================
- Coverage   86.96%   86.76%   -0.21%     
==========================================
  Files          96       98       +2     
  Lines       10605    11066     +461     
==========================================
+ Hits         9223     9601     +378     
- Misses       1382     1465      +83     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[tlambert03]

hey @fdrgsp, would be curious to get your take on this.

While setting up station 8, I found the conventional micromanager multi-window process of setting up channel config groups cumbersome. and also, you frequently find yourself unchecking a bunch of device types to get at the state devices that typically hold the fluorescence filters.

So this widget is more of an "opinionated" arrangement of stuff that's designed to make it easier to get at the most important settings when creating config groups. for example, we prune the list of light path properties to those most likely to be used (while still allowing to show all if desired). i think you'll recognize the inspiration :)

could you run python examples/channel_config_widget.py and see how you like it? and if it can be improved?

[fdrgsp]

i think you'll recognize the inspiration :)

🤣

could you run python examples/channel_config_widget.py and see how you like it? and if it can be improved?

I definitely ❤️ it! create the channel configs is much easier! I think that I would need to try it on a real microscope to understand what can be improved or modified but I agree and I think this should be a widget.

[marktsuchida]

I like the dedicated combo box for Core-Shutter and hiding it in the list of properties. I think similarly the camera's Exposure could be hidden by default, as it almost never should be in the config group.

(I've also fantasized about a config editor with a 2D table: properties in rows and presets in columns. There could be a second pane on the left that just lists properties, without values, with checkboxes to select which properties to include in the group and hence the 2D table. Or the 2D table could be the whole window, with add/remove buttons for both properties and presets.)

[tlambert03]

thanks for looking @marktsuchida :)

I've also fantasized about a config editor with a 2D table: properties in rows and presets in columns.

makes it a little harder to capture a case where one preset doesn't need to modify a specific property, right?

When I was first orienting myself to config groups, i found it slightly surprising that different presets within a group could actually have a different set of properties... but now actually I think it's quite powerful, and let's you really express the bare minimum number of things that must be set when switching to a new preset (while allowing non-critical things to just stay in whatever position they were last in)

In an effort, to make it a bit clearer which properties are selected, I've made the contrast a bit starker between a selected prop and an inactive one. and the preset names remain on the left

---

I think similarly the camera's Exposure could be hidden by default, as it almost never should be in the config group.

this one is kinda interesting actually. While it may feel like a very strange way to do things, the default way that Nikon Elements works on all of our stations is that exposure (and indeed many other camera properties) does go into the optical config settings. In elements, OCs are really much more "living/breathing things", such that when a user clicks on the button to switch to the red channel, and then changes the exposure as they are optimizing their image, those changes actually persist in that config (and then the user would not put a channel-specific exposure in the channels selector in the MDA widget as we and MMStudio (?) currently do).

not necessarily voting one way or the other, but it's interesting to think about.

[tlambert03]

I've also fantasized about a config editor with a 2D table: properties in rows and presets in columns. There could be a second pane on the left that just lists properties, without values

a nice thing about having this all in python is that it would probably only take a couple hours for you to make an alternative config widget exactly how you want it and use it in your app :)

[marktsuchida]

makes it a little harder to capture a case where one preset doesn't need to modify a specific property, right?

True, though I think that could still be handled by an additional checkbox in each cell. Anyway, just putting the idea out there.

I was also surprised to see that the MMCore code is actually written to allow presets that don't have all the properties of the group. Loading such a config might break MMStudio, but that shouldn't restrict us, of course.

In elements, OCs are really much more "living/breathing things"

I think for this to work the config groups need to be composed of more intuitive parameters that all users can easily understand. We could maybe do this if we had something like a system of virtual properties that can (completely) hide the lower-level ones from the devices. Or the ability to cascade config groups. But an interesting way to do things for sure.

[tlambert03]

ok, this PR is in a decent state now.

Things I haven't implemented but have discussed:

• a "basic/expert" tab widget. The current PR simplifies a lot of things by using heuristics to highlight the "most likely" things that someone would want to edit: making the common use cases easy. But we also need to make sure to make the uncommon use cases possible. It may already be possible simply be checking the "show all properties" checkbox. But another option is to have an "expert" mode that simply gives the full device property table. DEFERRED
• the groupbox checkboxes are still unimplemented. The intention was for those to essentially gate a whole group of things at once (for example, unchecking the "camera" group box would mean that the preset excludes all camera settings... while making it easier for them to retoggle them all back on). I'm still unsure if this is good. Elements has this, but it might be confusing
• all checked properties should be visible, regardless of whether the show all properties checkbox is checked (even if they would have been hidden by the heuristic).
• TODO: Mouse wheel should not affect PropertyWidgets when they are embedded in a PropertyBrowser #372 is still annoying (but not part of this PR)

[tlambert03]

see #446 and related PRs