[Panel-devel] Sensors and Meters in SK

[Aaron J. Seigo]

On Thursday 08 September 2005 11:33, Vinay Khaitan wrote:
> > 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.

that would be somewhat daft since the point of "sensors" and "meters" is, in 
the common case, to use meters to show the output of sensors. so that common 
pattern of usage should be optimized for. this isn't about hardwiring them 
together to the exclusion of all other possibilities, but providing an easy 
and future-proof path to doing what will certainly be the most common 
activity: connecting sensors to meters.

> 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 .

not at all. there are several ways around this. one is to use:

	QVariant::QVariant ( const QMap<QString, QVariant> & val )

and require that meters accept a QMap as a possible input. of course this 
leaves the "one sensor with N outputs distributed across N meters" so you can 
have 3 CPUs and set up one bar per CPU. in which case, i'd say this calls for 
a "multimeter" which takes a QMap and displays one output widget per value in 
the map. which solves that scenario neatly. internally the multimeter would 
take individual meters and manage them "by hand" internally, but again this 
would encapsulate this behaviour in one class instead of forcing applet 
developers to repeat this task over and over.

another thing to keep in mind is that there is nothing that says one can't, 
for the odd case, do everything by hand as you describe. so i could hook up a 
meter to signals internal to my applet that were emitted upon some custon 
event if i really wanted; heck one should be able to manually call 
meter->setValue(foobar); but common things (connecting a sensor to a meter) 
should be simple to accomplish and not require deep knowledge of 
implementation details.

> 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).

this is why one sets down some basic patterns during design. patterns rarely 
emerge on their own, they are usually set down by the people designing the 
software.

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

erm. this is hardly "OO design". what you're doing is saying there is no 
design or pattern, so leave everything up to the applet writers. to wit, it's 
the opposite of "design". =/

the biggest down side to doing it the "connect everything yourself" approach 
is that by exposing that level of detail in each applet, if we ever decide to 
change how sensors or meters work (e.g. wish to add some additional 
functionality to them, or change the input or output mechanisms) then every 
single applet that depends on them will have to reflect those changes as 
well.

it also means that if an applet writer wishes to change the meter in use or 
the sensor in use then they have to change more code than necessary. unless, 
of course, it's done the same way for every sensor and meter in which case it 
should be abstracted away.

applets should be shielded from the implementation details as much as possible 
and the sensors and meters should be able to be plugged in together as simply 
as possible. using a visitor type pattern keeps the implementation specific 
details as close to the implementation as possible in this case.

-- 
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/20050909/42d97893/attachment.pgp