Proposal: Script access to improved config groups
Opened this issue · 4 comments
I’m working on a plugin where I would like to use config groups to abstract out some of the hardware specifics. However I have realized that unlike in the MMStudio UI, in CMMCore there is only handling for config groups with finite presets denoted by a String name.
Handling of config groups with continuous ranges of float or int values is actually done right in the user interface code:
I think that it makes sense to have access to this augmented config group handling from the Studio interface, but I wanted to see if such an addition to Studio would be accepted before working on it. Any feedback is welcome.
Thanks,
Nick
@nanthony21 I would certainly love to see improvement in the handling of single-property configuration groups. This was always a hack in the GUI.
I guess the question is what access to provide. Perhaps the simplest would be a boolean method that returns true when the given group should be treated as a numeric range -- so that code that is aware of this feature can special-case such groups. A common use case might be to simply exclude such groups from processing. For example, the Channel Group selection should probably do this, as single-property range groups are never used as the channel group (I hope).
Perhaps you had other ideas?
The only important constraint I can think of is that the meaning of existing .cfg files should not change, but it doesn't sound like you are thinking of a change at that level.
There are other issues with the special handling of these groups. The major one is that sometimes the user wants a normal config group with a single numerical property and specify a set of discrete values. For example, I might have a laser power property that allows 0 to 100% but want to standardize my experiments to 25%, 50%, and 100% power. Right now the only way to achieve this (from the GUI at least) is to include a second, unchanging/irrelevant property as a workaround. But it would be nice to leave room for improving this in the future. (It might be possible to create such a group by manually editing the .cfg file -- I haven't checked.)
I guess the first thing to decide is at what level this change should be made.
At the MMStudio Java level I think the org.micromanager.internal.utils.PropertyItem class already provides most of the needed functionality it just needs to be made accessible from the Studio interface and maybe expanded on a little bit.
Making this change at the CMMCore level might make more sense in the long-run but would probably be a lot more work to make sure it doesn't cause problems.
@nanthony21 I agree. Happy to review anything you propose for MMStudio.
@marktsuchida Ok, when I find the time I'll plan on making an attempt at adding this to MMStudio, I'd rather not dig into CMMCore right now.