[Panel-devel] applets and multiple dataengines

[Thomas Fjellstrom]

On Tue September 25 2007, Rüdiger Hacke wrote:
> 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!

Should you not create a separate applet for each data source, and just group 
them into a larger "container"? I'm pretty sure this is the intention.

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



-- 
Thomas Fjellstrom
tfjellstrom at strangesoft.net