[Panel-devel] Design of Sensor and meters

[Vinay Khaitan]

I think your doubts are within the framework I proposed.

> 
> I think this isn't the real problem. In fact this is a feature of SK right
> now, using format strings to specify how a meter should show the data
> received from a sensor.


Well, that's why I wrote that proposition is from "combining old, new " 
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,"who knows the 
format of return value? theme writer. So let us leverage this fact through 
format string". But I think, I have extended it.

But this works to some extent. For instance, imagine you want to create an
> applet that shows the most recently used applications. You could use the
> tasksensor, but you need a logic that can't be created simply with a 
> format
> string. Or imagine you want show the average load of the cpu, or the last
> words looked up in a dictionary. I mean, things that don't depend on the
> current state of a sensor, but on the history of a sensor.


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

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.

I think the best solution is allowing the developer declaring custom meters 
> in
> the script, because you can't automatize data processing in all cases. The
> common case would be pluging some sensor to a default meter, but you could
> redefine the update methods inside the scripting, or declare new meters to
> solve all problems.


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

I think, you doubts are possible to be solved within my proposition.

Vinay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20050913/e011ab7c/attachment.html