I think your doubts are within the framework I proposed.<br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>I think this isn't the real problem. In fact this is a feature of SK right
<br>now, using format strings to specify how a meter should show the data<br>received from a sensor.</blockquote><div><br>
Well, that's why I wrote that proposition is from&nbsp; &quot;combining old,
new &quot;&nbsp; idea. The simplicity of format string struck to me after
understanding the specification of current SK. I had one another idea,
but format string looked to me a lot better, because it satisfies my
logic,&quot;who knows the format of return value? theme writer. So let us
leverage this fact through format string&quot;. But&nbsp; I think, I have
extended it.<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;">But this works to some extent. For instance, imagine you want to create an<br>applet that shows the most recently used applications. You could use the
<br>tasksensor, but you need a logic that can't be created simply with a format<br>string. Or imagine you want show the average load of the cpu, or the last<br>words looked up in a dictionary. I mean, things that don't depend on the
<br>current state of a sensor, but on the history of a sensor.</blockquote><div><br>
This is a good point. There can be many usage of sensors. All of them
cant be achieved by just connecting sensor to meter. That's why I had
demanded that power should not be taken off from sensor,meter,theme
writers.<br>
To solve your case, the script writer would get the value at certain
interval from sensor and will keep it. Then,as history is available to
script, the script writer would use that to setData() in meter directly
instead of connecting to sensor.<br>
<br>
I think, such type of things are done in current Sk too by some themes.
As the processing of data becomes complex, theme writer has to resort
to script and programming.<br>
&nbsp;</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I think the best solution is allowing the developer declaring custom meters in<br>
the script, because you can't automatize data processing in all cases. The<br>common case would be pluging some sensor to a default meter, but you could<br>redefine the update methods inside the scripting, or declare new meters to
<br>solve all problems.</blockquote><div><br>
The custom meter and sensor would be available as plugins definitely.
But your idea of custom meter in scripting too looks good to me. We
need to think about it.<br>
As far as update is concerned, I think, the normal update of sensor is
okay, as if you like a different method of updates, you have the direct
manipulation of meters in your hand. process data yourself, update
meter yourself.<br>
<br>
I think, you doubts are possible to be solved within my proposition.<br>
<br>
Vinay<br>
</div></div><br>