[Panel-devel] Design of Sensor and meters

[Pedro Suarez Casal]

El Martes, 13 de Septiembre de 2005 06:40, Vinay Khaitan escribió:
> Pedro has done some refactoring of superkaramba. He has encountered some
> design troubles. They are similiar to what I had earlier talked about i.e.
> meters dont know the format sensor's return value. And type of return value
> doesn't give any information about that.
> So I am proposing a solution to it. it is from combining old, new and mine
> ideas.
>
> class arbitSensor::public Sensor
> {
> /* all the sensors will have some user readable/writable attributes. They
> can be set from themefile in format sensor.updateInterval=1000 */
> Q_PROPERTY(int updateInterval READ updateInterval WRITE setUpdateInterval)
> /*We will use Q_PROPERTY macro. so that setProperty() work.*/
> /* All the Sensors return values about information contained into them. But
> how the meters would understand the format of return values(see my earlier
> example in a mail, of tasksensor)? Pedro was getting some trouble with it.
> I ask to dump the idea of single return value.
> I propose that there would be a "value" parameter in theme file which will
> have values with some %arguments.
> taking example of richtextlabel and bar connected to cpusensor,
> (I dont want to use cryptic %u etc., they would become difficult in long
> run)
> RICHTEXTLABEL value="cpu load of cpu0= %cpu0 user=%cpu0.user
> sytem=%cpu.system"
> BAR value=%cpu0.system , we will use the dotted form.
> Meters have setValue() slot. they would ask sensor for the value of
> %cpu0.system in QString and sensors would return value in QString.
> */
>
> QString returnValue(QString data) ; //data=cpu0.user, returns QString::null
> if data is not supported
>
> signals:
> void update(); //no parameter
> }
>
> class arbitMeter: public Meter
> {
> Q_PROPERTY(QString value READ value WRITE setValue); //all the meters have
> some attributes which can be set
>
> void setValue( QString);
> void attachToSensor(Sensor* sensor)
> {
> connect(sensor, SIGNAL(update()),this,SLOT(updateNow()));
> //other stuff
> }
>
> //I am forgetting some other necessary functions
>
> }
>
> The idea of multimeter appealed me.
> We can have things like this in theme file,
>
> MULTIMETER meter=bar number=2 orientation=horizontal, separationX=50
> separationY=50 value.1=cpu0.system bar.x=0 bar.y=etc
> value.2=cpu1.systemSENSOR=cpusensor
>
> The separation stuff would set the separation of multiple meters.
> orientation is separation orientation.
>
> So with this format, making of (non interactive )taskbar with the
> tasksensor I described in one mail is just one line,
> (x is for variable number)
> MULTIMETER meter=RICHTEXTLABEL number=x value.x=task.x separation=(50,50)
> orientation=horizontal mask=alpha, background=beta etc.
>
> I know, this idea would be modified, but IMHO, this works smoothly from the
> point of view of separation of meters and sensors, theme creation ease and
> superkarama coding.
>
> Comments?
>
I think this isn't the real problem. In fact this is a feature of SK right 
now, using format strings to specify how a meter should show the data 
received from a sensor. 

But this works to some extent. For instance, imagine you want to create an 
applet that shows the most recently used applications. You could use the 
tasksensor, but you need a logic that can't be created simply with a format 
string. Or imagine you want show the average load of the cpu, or the last 
words looked up in a dictionary. I mean, things that don't depend on the 
current state of a sensor, but on the history of a sensor.

I think the best solution is allowing the developer declaring custom meters in 
the script, because you can't automatize data processing in all cases. The 
common case would be pluging some sensor to a default meter, but you could 
redefine the update methods inside the scripting, or declare new meters to 
solve all problems.

> Vinay Khaitan