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. >> True, but in both cases it would have needed a patch. >> Offtopic: it's too bad Plasma does not have a DBus call to reload its >> config. > > you really don't want to do that; this implies something other than plasma- > desktop has touched the config file(s) but plasma-desktop may have written > over it since then. due to limitations in kconfig this whole "change the > config file on disk behind the app's back" is a non-starter. OK. >> Could be handy when going from one distro release to another >> (/me thinks about the switch between knetworkmanager the executable and >> knetworkmanager the plasmoid). I'll try to implement this if I find time. > > 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. Aurelien _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel