[Panel-devel] Sensors and Meters in SK

[Aaron J. Seigo]

On Wednesday 07 September 2005 01:28, Vinay Khaitan wrote:
> type(), which says what type of data is returned by the sensor. it can be
> bool,int,QString,QMap<QString,QString>
> returnValue() which actually returns the value.

sounds like a job for QVariant.

> 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 last bit assumes that the general usual habit is to create sensors first 
then meters.

> Now, As meters are very customizable, these meters can be used even by
> applets and extenders.
> meters would go into libplasma. Sensors would become plasma engine.

correct. we may eventually end up splitting out the GUI elements in libplasma 
into a separate lib at some point, depending on how many there are and how 
the lib gets used, but for now i'm going to just go the KISS way and say 
"throw all that stuff together". it's easy enough to split out the lib at a 
future point (but well in advance of KDE4) if necessary / desirable.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20050908/3ce43005/attachment.pgp