<html><head><meta name="qrichtext" content="1" /></head><body style="font-size:11pt;font-family:Sans Serif">
<p><span style="color:#008000">> and what's an "AbstractEngine"? shouldn't that be "AbstractSensor"? "plasma</span></p>
<p><span style="color:#008000">> engine" is broader in concept that just Sensors. for instance, while we</span></p>
<p><span style="color:#008000">> could provide a Sensor driven model for libtaskmanager, it would really be</span></p>
<p><span style="color:#008000">> a "round peg, square hole" sort of deal.</span></p>
<p></p>
<p>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.</p>
<p></p>
<p><span style="color:#008000">></span></p>
<p><span style="color:#007000">> > In this case, the only difference would be how Meters and Sensors are</span></p>
<p><span style="color:#007000">> > connected. Instead of calling a method in the Sensor for creating the</span></p>
<p><span style="color:#007000">> > connection, the Meter itself would create it.</span></p>
<p><span style="color:#008000">></span></p>
<p><span style="color:#008000">> that would work, but IMHO not as well.the code path would be:</span></p>
<p><span style="color:#008000">></span></p>
<p><span style="color:#008000">> Sensor emits a signal</span></p>
<p><span style="color:#008000">> Meter requests the value for the Sensor</span></p>
<p><span style="color:#008000">> Sensor returns the requested value</span></p>
<p><span style="color:#008000">> Meter displays it</span></p>
<p><span style="color:#008000">></span></p>
<p><span style="color:#008000">> with visitor, you'd just get:</span></p>
<p><span style="color:#008000">></span></p>
<p><span style="color:#008000">> Sensor emits a signal with the value(s)</span></p>
<p><span style="color:#008000">> Meter displays it</span></p>
<p><span style="color:#008000">></span></p>
<p><span style="color:#008000">> if you wanted to keep the class dependency down to just "Meter knows of</span></p>
<p><span style="color:#008000">> Sensor" then have Meter do the connecting of the Sensor signal to itself.</span></p>
<p><span style="color:#008000">> or have a third class that does the connecting. i just don't see the need</span></p>
<p><span style="color:#008000">> for the extra code paths that will be executed on _every update_ when we</span></p>
<p><span style="color:#008000">> could simply do the "right connection" once per sensor/meter pair.</span></p>
<p><span style="color:#008000">></span></p>
<p><span style="color:#008000">> furthermore, but letting the Sensor do the connecting, one doesn't have to</span></p>
<p><span style="color:#008000">> expose any Sensor-specific API to Meter allowing for each Sensor to be as</span></p>
<p><span style="color:#008000">> specialized as it feels the need for. and i suspect that Sensors will need</span></p>
<p><span style="color:#008000">> more specialization than Meters will as Meters have a fairly well define</span></p>
<p><span style="color:#008000">> purpose (show values to the user) while Sensors are far broader in scope.</span></p>
<p><span style="color:#008000">></span></p>
<p></p>
<p>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 :)</p>
<p></p>
<p><span style="color:#007000">> > This way Sensors could be used</span></p>
<p><span style="color:#007000">> > with other elements different from Meters.</span></p>
<p><span style="color:#008000">></span></p>
<p><span style="color:#008000">> sensors could still be used with elements other than meters. it would just</span></p>
<p><span style="color:#008000">> be EASIER to use them with meters. however, one has to ask: how often will</span></p>
<p><span style="color:#008000">> any sensor be used with something that isn't a meter? the answer will</span></p>
<p><span style="color:#008000">> dictate how much that should influence the design. i'd look at superkaramba</span></p>
<p><span style="color:#008000">> widgets, kicker applets, mac dashboard widgets, gdesklets and konfabulators</span></p>
<p><span style="color:#008000">> for the answer.</span></p>
<p><span style="color:#008000">></span></p>
<p><span style="color:#008000">> i really don't see the issue with saying "meters and sensors know about</span></p>
<p><span style="color:#008000">> each other" and keeping the base classes for each very basic and simple. in</span></p>
<p><span style="color:#008000">> fact, Sensor should be a QObject, Meter a QWidget. Sensor should only</span></p>
<p><span style="color:#008000">> define the signal which carries a QVariant and perhaps the necessary</span></p>
<p><span style="color:#008000">> infrastructure for the pattern used to connect Sensors and Meters; Meters</span></p>
<p><span style="color:#008000">> should only have the means necessary to connect with Sensors and a standard</span></p>
<p><span style="color:#008000">> (set of?) slots to accept the Sensor new value(s) signal.</span></p>
<p><span style="color:#008000">></span></p>
<p><span style="color:#008000">> hell if you _really_ wanted to you could make Meter an interface only and</span></p>
<p><span style="color:#008000">> require multiple inheritance (e.g. MyMeter : public QWidget, public</span></p>
<p><span style="color:#008000">> Plasma:Meter) at which point a sensor could be used with "anything".</span></p>
<p><span style="color:#008000">> granted MI isn't the prettiest thing, but it may be just what the doc</span></p>
<p><span style="color:#008000">> ordered here. my primary concern is scripting languages that don't allow</span></p>
<p><span style="color:#008000">> for MI, such as Ruby. though Ruby could probably use mix ins instead to</span></p>
<p><span style="color:#008000">> include the MyMeter interface. still, i'd be a bit concerned about</span></p>
<p><span style="color:#008000">> requiring some sort of multiple inheritence / implementation scheme and not</span></p>
<p><span style="color:#008000">> bother.</span></p>
<p></p>
<p>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. </p>
<p></p>
<p>But anyway, you are right, it could be done using a sort of MI depending on the language.</p>
<p></p>
<p></p>
</body></html>