[Panel-devel] Sensors and Meters in SK

[Aaron J. Seigo]

On Saturday 10 September 2005 09:44, Pedro Suarez Casal wrote:
> Our idea was to use the Observer pattern as I said in the previous mail. I
> send you it so you can give your opinion. It's an Umbrello diagram.

i have to say that UML remains one of the bigger disappointments in terms of 
providing a way to communicate algorithmic ideas between people =( maybe 
that's just me ... anyways

whether you use observer or visitor, what matters at the end of the day is how 
easy it is for applet developers to do the common tasks and whether it's 
possible or not for the truly motivated to do non-common or difficult tasks.

the common case seems to be: create a sensor, plug it into one or more meters.

and what's an "AbstractEngine"? shouldn't that be "AbstractSensor"? "plasma 
engine" is broader in concept that just Sensors. for instance, while we could 
provide a Sensor driven model for libtaskmanager, it would really be a "round 
peg, square hole" sort of deal.

> In this case, the only difference would be how Meters and Sensors are 
> connected. Instead of calling a method in the Sensor for creating the 
> connection, the Meter itself would create it.

that would work, but IMHO not as well.the code path would be:

	Sensor emits a signal
	Meter requests the value for the Sensor
	Sensor returns the requested value
	Meter displays it

with visitor, you'd just get:

	Sensor emits a signal with the value(s)
	Meter displays it

if you wanted to keep the class dependency down to just "Meter knows of 
Sensor" then have Meter do the connecting of the Sensor signal to itself. or 
have a third class that does the connecting. i just don't see the need for 
the extra code paths that will be executed on _every update_ when we could 
simply do the "right connection" once per sensor/meter pair.

furthermore, but letting the Sensor do the connecting, one doesn't have to 
expose any Sensor-specific API to Meter allowing for each Sensor to be as 
specialized as it feels the need for. and i suspect that Sensors will need 
more specialization than Meters will as Meters have a fairly well define 
purpose (show values to the user) while Sensors are far broader in scope.

> This way Sensors could be used  
> with other elements different from Meters.

sensors could still be used with elements other than meters. it would just be 
EASIER to use them with meters. however, one has to ask: how often will any 
sensor be used with something that isn't a meter? the answer will dictate how 
much that should influence the design. i'd look at superkaramba widgets, 
kicker applets, mac dashboard widgets, gdesklets and konfabulators for the 
answer.

i really don't see the issue with saying "meters and sensors know about each 
other" and keeping the base classes for each very basic and simple. in fact, 
Sensor should be a QObject, Meter a QWidget. Sensor should only define the 
signal which carries a QVariant and perhaps the necessary infrastructure for 
the pattern used to connect Sensors and Meters; Meters should only have the 
means necessary to connect with Sensors and a standard (set of?) slots to 
accept the Sensor new value(s) signal.

hell if you _really_ wanted to you could make Meter an interface only and 
require multiple inheritance (e.g. MyMeter : public QWidget, public 
Plasma:Meter) at which point a sensor could be used with "anything". granted 
MI isn't the prettiest thing, but it may be just what the doc ordered here. 
my primary concern is scripting languages that don't allow for MI, such as 
Ruby. though Ruby could probably use mix ins instead to include the MyMeter 
interface. still, i'd be a bit concerned about requiring some sort of 
multiple inheritence / implementation scheme and not bother.

-- 
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/20050911/c8703535/attachment.pgp