xpedaq started off with two single, monolithic configuration files---one for the detector configuration and one for the user preferences. It is now clear that different applications need different configuration file and we need a more flexible facility, e.g:
for xpepeds the multicast field in the user preferences, as well as some of the fields in the detector configuration, do not make sense (right now we disable the corresponding widgets)
xpemon has its own preference file
xpereg is again peculiar in the preferences.
One possibility would be to have a base class with an underlying std::map or two underlying std::vectors---one for the names and one for the values. The fact that the values can have multiple types might be a slight issue. Need to think about this.
Another option is follow the pMonitorPreference example and make all the class members public---at least we avoid tons of lines of code to access and set them.
xpedaq started off with two single, monolithic configuration files---one for the detector configuration and one for the user preferences. It is now clear that different applications need different configuration file and we need a more flexible facility, e.g:
One possibility would be to have a base class with an underlying std::map or two underlying std::vectors---one for the names and one for the values. The fact that the values can have multiple types might be a slight issue. Need to think about this.