dcop auto-overuse
Lubos Lunak
l.lunak at suse.cz
Thu Dec 11 09:37:01 CET 2003
On Wednesday 10 of December 2003 15:07, Oswald Buddenhagen wrote:
> On Wed, Dec 10, 2003 at 01:14:26PM +0100, Lubos Lunak wrote:
> > This is just begging for trouble. If there will be dozens of places
> > where one will have to do this manually, at least in some of the
> > places this will be wrong.
>
> i think you're exaggerating the issue ... synchronization with a
> dcopserver startup in the background (and for that matter, even
> launching one) can be done transparently in the dcop classes - just like
> it is now, only further down the invocation graph.
Sure. And what about klauncher, kded and its modules, kconf_update,
kbuildsycoca?
>
> > I think a sufficient solution for this could be one or both of:
> > - clearly document and make people know the fact that they can run
> > 'kdeinit' manually and then all daemons will stay in memory and KDE
> > apps will start quickly
>
> i suggest a reality check on this idea ...
>
> > - make longer the interval between the time when dcopserver detects
> > there's no KDE app running and the time when klauncher shuts down
> > kdeinit+daemons (it's only 10 seconds now, kdelibs/dcop/dcopserver.cpp
> > DCOPServer::removeConnection()).
>
> that's pretty much pointless without libCrystalBall. ;) the only viable
> solution would be not terminating at all till the x connection breaks
> down, but as a kde-nonuser i'd absolutely hate that.
> it wouldn't help with first startup anyway (and that matters for a first
> impression when somebody tries a new app).
> btw, the delayed shutdown at it is now sucks big time if you run an app
> from the command line.
>
> greetings
--
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o. e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27 tel: +420 2 9654 2373
190 00 Praha 9 fax: +420 2 9654 2374
Czech Republic http://www.suse.cz/
More information about the Kde-optimize
mailing list