[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: [Panel-devel] applets and multiple dataengines
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2007-09-25 13:27:21
Message-ID: 200709250727.21853.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 25 September 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

right, and you'd connect each of those sources up to separate *visualizations* 
within your applet, no? e.g. a graph(s) for the network activity, a text 
label for the time, etc, etc.

trying to dispatch all the messages from your Applet subclass to various 
widgets drawing things sounds ... less than optimal to me.

> > *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 :)

no, that's not why. the reason Applets don't do this themselves is because the 
code necessary is in the Applet class itself along with DataEngineManager. 
the engines are shared between visualizations (and applets) so there is a 
reference counting that happens and resources are released as it becomes 
possible to do so (per-source, actually).

expecting each Applet writer to do this themselves in their code would be just 
inane, error prone (think of how many people would forget to do it or do it 
incorrectly) and thankfully unnecessary. plasma is smart so your code doesn't 
have to be. ;)

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

=)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech

[Attachment #5 (application/pgp-signature)]

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