<div><div><br>
I thought about it and I am convinced that meters and sensors should be related.<br>
</div><div> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> they dont know each other (this is what matt<br>> broadstone like to call OO design). There are reasons for it. Let's take an
<br>> example of cpusensor on multi-cpu system. It returns , let's say,<br>> QMap<QString, int> and contents are....<br>> cpu0->700<br>> cpu1->2400<br>> Now, bar->acceptSensor(cpusensor) would show cpu0 or cpu1 ? It wil have to
<br>> skip it! but we want that bar should show cpu0 .<br><br>not at all. there are several ways around this. one is to use:<br><br> QVariant::QVariant ( const QMap<QString, QVariant> & val )<br><br>and require that meters accept a QMap as a possible input. of course this
<br>leaves the "one sensor with N outputs distributed across N meters" so you can<br>have 3 CPUs and set up one bar per CPU. in which case, i'd say this calls for<br>a "multimeter" which takes a QMap and displays one output widget per value in
<br>the map. which solves that scenario neatly. internally the multimeter would<br>take individual meters and manage them "by hand" internally, but again this<br>would encapsulate this behaviour in one class instead of forcing applet
<br>developers to repeat this task over and over.</blockquote><div><br>
<br>
Idea of multimeter is good enough to be thought upon. Actually I
was thinking about many possible odd cases, e.g. TaskSensor. in
QMap<QString,QString> it will return <br>
All tasks->konqueror,kdevelop,....<br>
Active task->kdevelop<br>
................etc.<br>
<br>
This is useful information which can be show for switching windows in a
funky karamba theme. Now just connecting this to meter is not good
enough as meters dont know that tasks are separated by commas in first
key.<br>
<br>
BUT, you have granted that for odd cases, there would certainly be
direct manipulation possible. it means your thought about sensor and
meters is superset of my idea. So it is better to have sensors and
meters connection to ease the life of theme creator :) . Actually
I was worried that power should not be taken off from theme and sensor
plugin creators.<br>
</div><div> <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">erm. this is hardly "OO design". what you're doing is saying there is no<br>
design or pattern, so leave everything up to the applet writers. to wit, it's<br>the opposite of "design". =/</blockquote><div><br>
I am not so daft, please. The OO design doesn't refers to Themes, but
superkaramba's own codebase. In our codebase, for sensors, I am saying
that all the sensors would <br>
return value in returnValue(), <br>
update Signal in update() .......etc. <br>
Whereas there are many other ways to do things for every sensor by exposing many internal function.<br>
The thing I have thought upon is that, when We would expose a interface
to sensor plugins, there can be many different types of plugins, which
kde-looks people can come up with. So restricting the pattern of
returning data would be severely posing restrictions upon plugin
writers. <br>
<br>
I was leaving everything upto theme writers, not to sensor and meter
plugin writers. We are defining clear interface to sensor and meter
plugin writers not to theme writers.<br>
But As long as your idea is superset of mine, I am happy.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">the biggest down side to doing it the "connect everything yourself" approach
<br>is that by exposing that level of detail in each applet, if we ever decide to<br>change how sensors or meters work (e.g. wish to add some additional<br>functionality to them, or change the input or output mechanisms) then every
<br>single applet that depends on them will have to reflect those changes as<br>well.</blockquote><div><br>
Wait...Wait. We are not exposing all internal working of sensors and meters. But only input and Output mechanism.<br>
But if we dont expose input output interface, it would severely
restrict the sensor and plugin writers. Sensor plugin writers will have
to think how the meters connected with my sensor would show my sensor?
If that doesn't come out to be sufficient, then what would he do? so we
need to define input/output interface.<br>
</div><br></div>Thanks for some nice inputs,<br>
<br>
Vinay Khaitan<br>