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.<br><br><div><span class="gmail_quote">On 9/12/05, <b class="gmail_sendername">Vinay Khaitan</b> &lt;<a href="mailto:vkhaitan@gmail.com">vkhaitan@gmail.com</a>&gt; wrote:
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.&nbsp; meters dont know the format sensor's return value. And
type of return value doesn't give any information about that.<br>
So I am proposing a solution to it. it is from combining old, new and mine ideas.<br>
<br>
class arbitSensor::public Sensor<br>
{<br>
/* all the sensors will have some user readable/writable attributes.
They can be set from themefile in format sensor.updateInterval=1000 */<br>
Q_PROPERTY(int updateInterval READ updateInterval WRITE
setUpdateInterval) /*We will use Q_PROPERTY macro. so that
setProperty() work.*/<br>
/* All the Sensors return values&nbsp; 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.<br>
I ask to dump the idea of single return value.<br>
I propose that there would be a &quot;value&quot; parameter in theme file which will have values with some %arguments.<br>
taking example of richtextlabel and bar connected to cpusensor,<br>
(I dont want to use cryptic %u etc., they would become difficult in long run)<br>
RICHTEXTLABEL value=&quot;cpu load of cpu0= %cpu0 user=%cpu0.user sytem=%cpu.system&quot;<br>
BAR value=%cpu0.system , we will use the dotted form.<br>
Meters have setValue() slot. they would ask sensor for the value of
%cpu0.system in QString and sensors would return value in QString.<br>
&nbsp;*/ <br>
<br>
QString returnValue(QString data) ;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
//data=cpu0.user, returns QString::null if data is not supported<br>
<br>
signals: <br>
&nbsp; void update();&nbsp; //no parameter<br>
}<br>
<br>
class arbitMeter: public Meter<br>
{<br>
Q_PROPERTY(QString value READ value WRITE setValue); //all the meters have some attributes which can be set<br>
<br>
void setValue( QString);<br>
void attachToSensor(Sensor*&nbsp; sensor)<br>
{<br>
&nbsp;connect(sensor, SIGNAL(update()),this,SLOT(updateNow()));<br>
//other stuff<br>
}<br>
<br>
//I am forgetting some other necessary functions<br>
<br>
}<br>
<br>
The idea of multimeter appealed me.<br>
We can have things like this in theme file,<br>
<br>
MULTIMETER meter=bar number=2 orientation=horizontal, separationX=50
separationY=50 value.1=cpu0.system bar.x=0 bar.y=etc
value.2=cpu1.system SENSOR=cpusensor <br>
<br>
The separation stuff would set the separation of multiple meters. orientation is separation orientation.<br>
<br>
So with this format, making of (non interactive )taskbar with the tasksensor I described in one mail is just one line,<br>
(x is for variable number)<br>
MULTIMETER meter=RICHTEXTLABEL number=x&nbsp; value.x=task.x&nbsp;
separation=(50,50) orientation=horizontal&nbsp; mask=alpha,
background=beta etc.<br>
<br>
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.<br>
<br>
Comments?<br><span class="sg">
<br>
Vinay Khaitan<br>
<br>



</span></blockquote></div><br>