[Panel-devel] applets and multiple dataengines

[Rüdiger Hacke]

Am Dienstag 25 September 2007 schrieb Aaron J. Seigo:
> On Saturday 22 September 2007, Rüdiger Hacke wrote:
> > I'm trying to write a little system monitor applet that should be able to
> > display various information using more than one DataEngine.
>
> could you provide a bit more detail on this, so i can understand the use
> case better?

Think gkrellm :)
Suppose you want an applet that displays time, cpu usage, disk and network 
activity. You would need the time, network and systemmonitor engines. I have 
to admit that for the current set of available engines I can not come up with 
an example of conflicting source names. I was just thinking that maybe later, 
with more engines... who knows.

But I know that this is indeed a corner case which can be taken care of by the 
applet if need be. So please don't let me distract you guys from the 
important stuff, seriously!

> > Now with the current API the visualization gets its data via
> >
> >     updated(QString sourceName, Plasma::DataEngine::Data data)
> >
> > If I am not mistaken, with just that I have no easy means to tell which
> > engine sent the data. If two engines happen to have sources with the same
> > name, things would get complicated.
>
> *sigh* well, unfortunately i had anticipated people to write things such
> that they would create visualizations and connect *a* source to *a*
> visualization; the multiple source per vis was really a corner case for
> multimeters and what not...

That already answers the second question I had in mind: why there is no method 
to release an engine if it's not used anymore :)

> > But perhaps it is possible to add a third parameter to the above
> > mentioned signal which indicates the DataEngine this is coming from.
> > Either name or pointer. (I'd opt for pointer because getting the engine's
> > name from the pointer is easy, the other way round is a little less
> > efficient)
>
> the pointer approach would break various purposeful design decisions that
> are meant to make things more data centric and easier for script writers.

Ah, didn't know that. Started toying with plasma a few weeks ago. It's fun 
btw.

Thanks,
Rudi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20070925/6850c683/attachment.pgp