Save current preset

[Ashwolaa]

When finishing to optimize a DAQ_viewer or a DAQ_Move, it would be very nice to save the parameter tree settings that we achieve. Currently the method consists in adding taking a screen capture and to then make a new preset with the correct values.

One could add a save/load button on the DAQ_viewer/DAQ_Move and a load button in the preset_manager

These files would be the config_plugin.toml or maybe a particular syntax should be applied. Something like:

config/config_plugin_name/nameofconfig.toml

[seb5g]

I think this could actually be redundant with the configuration file. Actually all settings within a plugin could have their default value read from its associated config file. modifying the config file would then do the job of storing the info.

I don't mind adding some button to update the config file entries according to their current values but there is actually something else to consider. We should make a difference between generic default values (thought by the developer) and specific ones needed on an experiment. Especially because one instrument plugin can have multiple instance with different default values (which is handled normally by the preset)

So maybe it would just be best to leave the config file for generic config and allow to save/load from other external files (which is very easy to produce/load as xml) specific configs you could generate when optimising. Then you would produce the preset out of them

[Ashwolaa]

I agree with your points but I think it would be user friendly to just load settings for specific actuator/viewer without making a new preset which will also be redundant as only one detector/actuator settings needs to be changed sometimes.

I made some changes to add some buttons (save/load) on top of the settings tree, now only on daq viewer but this could also be much more general as these parameter settings are used in many various places. I will push it on Monday (I was struggling to make icons).
I am using the XML form as you suggested. However, it seems currently that treeitem must be a group to have some children and allows a proper reconstruction. I'll look into it to permit non-group parent.

[seb5g]

done in PR #222