In the present scenario most sensors have several configuration options, and these are defined in a dict element called 'Params' in each sensor's class. The Sensor data Logger application uses this dictionary to autogenerate menus with the 'key' as the name , and corresponding 'values' as a submenu . When the user opens a menu and clicks on a 'value' , the 'value' is passed to a function whose name is the corresponsing key , and which must be defined in the sensor's class.
An Example to illustrate
The following Params dictionary defined in the class of MPU6050 creates a menu as shown in the second image

self.params = { 'powerUp':['Go'],
  'setGyroRange':[250,500,1000,2000],
  'setAccelRange':[2,4,8,16],
  'KalmanFilter':[.01,.1,1,10,100,1000,10000,'OFF']
}

||

As shown in the image , when the user clicks on '8' , MPU6050.setAccelRange(8) is executed.

There are obvious limitations to this approach:

• For functions with no arguments, a dummy variable is defined just so the user has something to click on.
• This does not work for functions which require an arbitrary user defined input. e.g. , the Kalman filter menu shows a range of pre-defined values, wherein it should actually be a QDoubleSpinBox input.

I propose the following changes:

• For functions with no arguments, the value field should be None , and the GUI should generate a QMenuAction instead of a QSubMenu.
• For functions with variable input arguments, the menu should display a QSlider/QSpinBox/QTextArea/QColorDialog etc . For such functions, instead of providing a list of values, a string mentioning the type of input must be declared. Possible types : integer,double,string etc.