[Panel-devel] Sensors and Meters in SK

[Pedro Suarez Casal]

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

Well, I think I should review it before send it :). I was playing with the diagram after the meetup, and I changed that for myself, but it wasn't meant to have the meaning of an Engine. Sorry for that.

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

Well, Observer pattern has two forms of implementation. That one, and other that is more similar to the "Visitor's way", wich with every update sends all data. Choose what you prefer, I think that isn't the problem. The problem is more related with "who connects with who", and that's what I tried to suggest, a different way for doing the connections. If you think the connections creator should be the Sensor, then I agree :)

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

We thought meters as we know them in SK would disappear. For instance, in SK a text label is a Meter, and this could change in the future. That's why we decided to abstract that. 

But anyway, you are right, it could be done using a sort of MI depending on the language.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20050911/7ad9e8d3/attachment.html