From kde-panel-devel Wed Sep 30 17:08:24 2009 From: "Aaron J. Seigo" Date: Wed, 30 Sep 2009 17:08:24 +0000 To: kde-panel-devel Subject: Re: Ayatana notifications for Plasma Message-Id: <200909301108.24565.aseigo () kde ! org> X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=125433056717851 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0395432433==" --===============0395432433== Content-Type: multipart/signed; boundary="nextPart1329158.UThmJAhchY"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1329158.UThmJAhchY Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On September 30, 2009, Aur=C3=A9lien G=C3=A2teau wrote: > Aaron J. Seigo wrote: > > On September 29, 2009, Aur=C3=A9lien G=C3=A2teau wrote: > >>>> Keep in mind that the > >>>> binary is started on demand, so it does not take any memory if you a= re > >>>> not using it (assuming it would automatically stop itself after a > >>>> while). > >>> > >>> Same goes for applets, dataengines... > >> > >> Can an applet unload itself from memory? What I meant with "stop itself > >> after a while", was the notify-osd executable calling exit(). I believe > >> your desktop would be a bit too clean if an applet called exit() :). > > > > the overhead of a running applet should be negligable unless it's doing > > something rather wrong. > > > > so while you can certainly have an applet remove itself you'd also need= a > > way to re-create it, position it properly, make sure any user adjustmen= ts > > previously made to it remain, etc. then there'd be the overhead of any > > re- layouts this triggers in the containment, etc. for the memory savin= gs > > that would result, this probably isn't worth it. >=20 > I agree. My point was that the perceived bloat of having a separate > executable running in the background could be compensated by having said > executable stop itself after some time, since DBus would restart it when > needed. for a separate process this makes sense; for a widget inside of plasma itse= lf=20 it's probably better not to bother destroying it and recreating it constant= ly.=20 for clarity, there are three approaches to this: * extensively modify existing upstream widgets, like the system tray * minimal modifications to upstream widgets, provide a new widget that also= =20 runs in plasma (as you did with the message thing) * minimal modifications to upstream widgets, run all the new stuff in a=20 separate process i think this conversation may be toggling between the first and last=20 approaches, when there is the middle approach available. > > this is why i wrote the QScript based system for controlling > > plasma-desktop. it supports update scripts. there's a file in > > workspace/plasma/design/ about it and i've blogged about it as well. >=20 > Oh! I'll forward this to Jonathan. I was thinking about adding a way for > kconf_update to run commands before and after updates (so that a script > could stop plasma-desktop, edit its configuration and restart it), but > this sounds better. at the very least it actually works ;) =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 Qt Development Frameworks --nextPart1329158.UThmJAhchY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAkrDkIgACgkQ1rcusafx20PJJwCgiSgtPh5UHCa7WlUBM75zZUUd 3LsAn2gzmAKIlSLZzN/5Ct59bNI+seWd =r3fl -----END PGP SIGNATURE----- --nextPart1329158.UThmJAhchY-- --===============0395432433== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel --===============0395432433==--