[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Ayatana notifications for Plasma
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2009-09-30 17:08:24
Message-ID: 200909301108.24565.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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" (application/pgp-signature)]

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


[prev in list] [next in list] [prev in thread] [next in thread]