[Panel-devel] Design of Sensor and meters

[Vinay Khaitan]

And I also think, we can ditch cpusensor and related sensor, in favour of 
ProcessSensor. I think, with the format given by me, ProcessSensor can used 
with same ease for cpusensor memsensor etc.

On 9/12/05, Vinay Khaitan <vkhaitan at gmail.com> wrote:
> 
> 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?
> 
> Vinay Khaitan
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20050913/a9dff6ff/attachment.html