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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel