[Panel-devel] engines, animators, oh my

Michael Olbrich michael-olbrich at web.de
Mon Jun 11 14:33:28 CEST 2007


On Sun, Jun 10, 2007 at 10:02:34AM -0600, Aaron J. Seigo wrote:
> On Sunday 10 June 2007, Michael Olbrich wrote:
> > For a lot of data engines (e.g. for stuff from /proc or /sys) the update
> > rate is rather arbitrary and may be different for different applets. I
> > don't think the current api can really handle this.
> 
> this is actually one of the primary reasons for DataEngines: applets -share- 
> the data aquisition, which allows data aquisition to be synchronized. the 
> DataEngine pushes updates out, applets should not be pulling updates on their 
> own. for applets sharing DataEngines, there is no concept of "different 
> update ticks"

And how do we decide what the correct polling frequency for a DataEngine
is? Let's use the example of the time DataEngine. Maybe I want a clock
applet with a resoution of 0.1 seconds. To do that the DataEngine has to
provide 10 updates/second. Another clock applet only shows hours and
minutes. Now I now disable the high resolution clock. Will the
DataEngine still provide 10 updates/second?
If so the end the DataEngine has to use the maximum polling frequency
even if no currently active applet needs sucha high resolution. And how
should we decide what the maximum polling frequency is?

Maybe we could load DataEngines multiple times with different
parameters? That would allow more generic data engines as well:
e.g.:
DataEngine: "fileContent"
Parameters:
filename="/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq"
interval=100

DataEngineManager::loadDataEngine(const QString& name,
                                  const QMap<QString, QVariant>& param);
maybe?

michael


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20070611/1f2b8a60/attachment.pgp 


More information about the Panel-devel mailing list