[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: [Panel-devel] Design of Sensor and meters
From: Vinay Khaitan <vkhaitan () gmail ! com>
Date: 2005-09-13 13:57:33
Message-ID: 56c5347705091306571353f840 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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
[Attachment #5 (text/html)]
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 "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.<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>
</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>
_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic