[Panel-devel] Sensors and Meters in SK

[Vinay Khaitan]

I thought about it and I am convinced that meters and sensors should be 
related.
 
> 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.



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 
All tasks->konqueror,kdevelop,....
Active task->kdevelop
................etc.

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.

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.
 
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". =/


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 
return value in returnValue(), 
update Signal in update() .......etc. 
Whereas there are many other ways to do things for every sensor by exposing 
many internal function.
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. 

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.
But As long as your idea is superset of mine, I am happy.

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.


Wait...Wait. We are not exposing all internal working of sensors and meters. 
But only input and Output mechanism.
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.

Thanks for some nice inputs,

Vinay Khaitan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20050910/5b4c1a76/attachment-0001.html