Mwe of a toml config defining a custom group

[seb5g]

solving PyMoDAQ/PyMoDAQ#473

In order to use more the plugin config file, it would be nice if a toml entry could be linked to a custom ParameterItem in the ParameterTree in the GUI. For instance a "group" (assigned to a ParameterGroup in the GUI) could be transformed into a scalable group, that would allow to add quickly some configurations. For instance, a keithley instruments can have dozens of channels. Adding some in the configuration file using a scalable group would be nice

The solution introduced by this PR is to add a parameter_type entry in the toml. The toml to Parameter parser would then try to load the corresponding Parameter or the default if no parameter_type is set!

a mwe is written in examples

[seb5g]

@loicguilmard could you have a look?
@PauloGitHB it could be of interest in particular because here we are facing a need for another Parameter serializer, this time using toml. But toml is minimal and at the opposite of xml and json one cannot add "attributes". Hence the adding of the group_type entry here. But they are many limitations: one cannot store in toml the fact that an entry could be removed by the user (in particular because it should be like this when using scalable groups) or that it should be readonly and many more...

One "trick" could be to store extra complex config in a full xml hence a complete one for one correspondance like the presets for instance. it would not be a general feature as I don't see much applications for this...

[loicguilmard]

nevermind i recreated a new env and i can see the functionnality.
I'll test it a bit more and propose something this afternoon if i have something to add

[loicguilmard]

So it's wonderful, i'll be saving a lot of time and it's a nice enhancement to have for people to manage their configuration from the GUI.

If i want a more evolved choice than just in a choice in a list (like a checkbox list), is it ok to add some gui logic in the ScalableCustomGroup.addNew ? Or should we have something in the pymodaq_gui ? or elsewhere in the plugin ?

[loicguilmard]

I don't understand why the customgroup from toml can't be loaded as scalable GroupParameter, becoming then removable :)

The limits and so on that aren't stored in the toml are in the scalable group anyway.
Saving the xml wouldn't serve any purpose, we shouldn't be able to insert new scalable groups from files.

I pushed another example with a custom popup QDialog to my fork https://github.com/loicguilmard/pymodaq_gui/tree/feature/custom_toml_group

Would it be the place/way to implement it, i know this example is pretty specific but may be there is some general behavior to centralized ? I know we'll use a similar QDialog for plugin_nidaq anyway.

[seb5g]

being removable has nothing to do with scalable. It just means the parameter has a "removable" option set to True. But how to store this in a minimal toml file? One option could be to store the options into a dedicated group, ie:

afloat = 12.3
abool = true
[agroup]
anotherfloat=2.7
awhatever= false
[agroup.param_options]
type = 'customgroupparameter'
removable = true
tip = "a scalable group to display instrument features"

but not sure it is the role of a toml to store this especially because we are having these in XML file already...

[loicguilmard]

being removable has nothing to do with scalable. It just means the parameter has a "removable" option set to True. But how to store this in a minimal toml file? One option could be to store the options into a dedicated group, ie:
...

but not sure it is the role of a toml to store this especially because we are having these in XML file already...

Could we provide this using the custom GroupParameter using a property or providing a constructor (method) from template (as the Add new is doing) ?

it's so handy to edit the toml file this way, it feels weird to open the file to remove entries :)

Can you remind me why you introduced a config_plugin.toml file on the top of the preset.xml ? It would clarify its purpose.

If you check the nidaqmx PR, the toml are imported in the plugin ParameterTree. So how would it fit with this current implementation ?