--===============1035470729==
Content-Type: multipart/signed;
  boundary="nextPart20895614.gXgzuv6hia";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart20895614.gXgzuv6hia
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Tuesday 25 September 2007, R=C3=BCdiger Hacke wrote:
> Am Dienstag 25 September 2007 schrieb Aaron J. Seigo:
> > On Saturday 22 September 2007, R=C3=BCdiger 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 *visualizatio=
ns*=20
within your applet, no? e.g. a graph(s) for the network activity, a text=20
label for the time, etc, etc.

trying to dispatch all the messages from your Applet subclass to various=20
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=20
code necessary is in the Applet class itself along with DataEngineManager.=
=20
the engines are shared between visualizations (and applets) so there is a=20
reference counting that happens and resources are released as it becomes=20
possible to do so (per-source, actually).

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

> > the pointer approach would break various purposeful design decisions th=
at
> > are meant to make things more data centric and easier for script writer=
s.
>
> Ah, didn't know that. Started toying with plasma a few weeks ago. It's fun
> btw.

=3D)

=2D-=20
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

--nextPart20895614.gXgzuv6hia
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBG+Qy51rcusafx20MRAsxLAJ911dcyiUiw8KHp1KaDZt892Wu9BACgnHnM
RxpXVJNWevan9+JdWG1zN28=
=n/2u
-----END PGP SIGNATURE-----

--nextPart20895614.gXgzuv6hia--

--===============1035470729==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel

--===============1035470729==--