[Panel-devel] Sensors and Meters in SK

[Vinay Khaitan]

> 
> 
> sounds like a job for QVariant.


correct. 

> theme write are responsible to connect meters to sensors. For example,
> > setBarValue(cpuload.returnValue()). then connecting sensors update 
> SIGNALS
> > to meters slots.
> 
> hrm... could this use sth like the visitor pattern? e.g.:
> 
> Plasma::Meter::acceptSensor(Plasma::Sensor* sensor);
> 
> and then the meter could check the QVariant returned by Sensor::type and 
> if it
> is supported call:
> 
> sensor->connectSignals(this);
> 
> if the QVariant::Type isn't supported, simply return w/out calling
> connectSignals.
> 
> and the sensor could then do The Right Thing with its signals. this would
> require having a standard set of meter slots, however. of course, if the 
> slot
> takes a QVariant, then that makes that pretty simple ;)
> 
> void Sensor::connectSignals(Plasma::Meter* meter)
> {
> connect(this, SIGNAL(somethingChanged(QVariant)),
> meter, SLOT(update(QVariant)));
> }
> 
> this doesn't prevent one from connecting more than one sensor to a meter,
> though perhaps Sensor::connectSignals could clear all connections to
> Meter::update first with:
> 
> disconnect(0, 0, meter, SLOT(update(QVariant)));
> 
> this way all an applet writer has to do is (in some imaginary scripting
> language):
> 
> Sensor sensor = CPUSensor this;
> Meter meter = BarMeter this;
> meter acceptSensor sensor;
> 
> heck, one could even offer a Meter ctor that took a sensor to create even 
> more
> convenience:
> 
> Sensor sensor = CPUSensor this;
> Meter meter = BarMeter this sensor;


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....
cpu0->700
cpu1->2400
Now, bar->acceptSensor(cpusensor) would show cpu0 or cpu1 ? It wil have to 
skip it! but we want that bar should show cpu0 .
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. The pattern of return is totally dependent on sensor(sensor 
can even be a plugin).
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).

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.
"In Imaginary scripting language" :-
Sensor sensor= cpusensor this;
Meter meter= BarMeter this;
meter.show(cpusensor.value()[cpu0]);

I hope I am clear. OO design has amazing benefits.

Vinay Khaitan

ps:- wotan, we did talk about all these things in meeting, but not in so 
detailed form.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20050909/e972edac/attachment.html