<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>sounds like a job for QVariant.</blockquote><div><br>
correct. <br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> theme write are responsible to connect meters to sensors. For example,<br>> setBarValue(
cpuload.returnValue()). then connecting sensors update SIGNALS<br>> to meters slots.<br><br>hrm... could this use sth like the visitor pattern? e.g.:<br><br>Plasma::Meter::acceptSensor(Plasma::Sensor* sensor);<br><br>and then the meter could check the QVariant returned by Sensor::type and if it
<br>is supported call:<br><br> sensor->connectSignals(this);<br><br>if the QVariant::Type isn't supported, simply return w/out calling<br>connectSignals.<br><br>and the sensor could then do The Right Thing with its signals. this would
<br>require having a standard set of meter slots, however. of course, if the slot<br>takes a QVariant, then that makes that pretty simple ;)<br><br> void Sensor::connectSignals(Plasma::Meter* meter)<br> {<br>
connect(this,
SIGNAL(somethingChanged(QVariant)),<br> meter,
SLOT(update(QVariant)));<br> }<br><br>this doesn't prevent one from connecting more than one sensor to a meter,<br>though perhaps Sensor::connectSignals could clear all connections to<br>Meter::update first with:<br>
<br> disconnect(0,
0, meter, SLOT(update(QVariant)));<br><br>this way all an applet writer has to do is (in some imaginary scripting<br>language):<br><br> Sensor sensor = CPUSensor this;<br> Meter meter = BarMeter this;<br> meter acceptSensor sensor;
<br><br>heck, one could even offer a Meter ctor that took a sensor to create even more<br>convenience:<br><br> Sensor sensor = CPUSensor this;<br> Meter meter = BarMeter this sensor;</blockquote><div><br>
This sounds to me like backward step. Our idea is to separate
meters and sensors althogether. they dont know each other (this is what
matt broadstone like to call OO design). There are reasons for it.
Let's take an example of cpusensor on multi-cpu system. It returns ,
let's say, QMap<QString, int> and contents are....<br>
cpu0->700<br>
cpu1->2400<br>
Now, bar->acceptSensor(cpusensor) would show cpu0 or cpu1 ? It wil have to skip it! but we want that bar should show cpu0 .<br>
<span style="font-weight: bold;">The important thing is not what is the
type of return value, but how the return value is arranged to show
system info. We dont know the pattern in advance at all. </span>The pattern of return is totally dependent on sensor(sensor can even be a plugin).<br>
The same problem is there with sensor->showInMeter(Meter*) . The
meters could be of different variety, which we dont know in
advance(when given as plugin).<br>
<br>
Who knows about the pattern of return and how the data is shown by
meter? IMO, only theme writer. So, we should expose an interface, which
they can utilize to show correct data.<br>
"In Imaginary scripting language" :-<br>
Sensor sensor= cpusensor this;<br>
Meter meter= BarMeter this;<br>
meter.show(cpusensor.value()[cpu0]);<br>
<br>
I hope I am clear. OO design has amazing benefits.<br>
</div><br>
Vinay Khaitan<br>
<br>
ps:- wotan, we did talk about all these things in meeting, but not in so detailed form. <br></div>