Ayatana notifications for Plasma
Aaron J. Seigo
aseigo at kde.org
Wed Sep 30 19:08:24 CEST 2009
On September 30, 2009, Aurélien Gâteau wrote:
> Aaron J. Seigo wrote:
> > On September 29, 2009, Aurélien Gâteau wrote:
> >>>> Keep in mind that the
> >>>> binary is started on demand, so it does not take any memory if you are
> >>>> 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 adjustments
> > 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 savings
> > that would result, this probably isn't worth it.
>
> 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 itself
it's probably better not to bother destroying it and recreating it constantly.
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
runs in plasma (as you did with the message thing)
* minimal modifications to upstream widgets, run all the new stuff in a
separate process
i think this conversation may be toggling between the first and last
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.
>
> 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 ;)
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090930/54d9e6e0/attachment.sig
More information about the Plasma-devel
mailing list