David Jarvie lists at astrojar.org.uk
Sun Mar 5 01:20:14 GMT 2006

On Saturday 04 March 2006 22:47, Scott Wheeler wrote:
> On Saturday 04 March 2006 23:08, Lubos Lunak wrote:
> > On Saturday 04 March 2006 23:03, Christian Esken wrote:
> > > Am Samstag, 4. März 2006 22:24 schrieb Lubos Lunak:
> > > >  Actually we support 3 phases Really Soon(TM). As soon as my startup
> > > > patches are in SVN. Phase 0 for kdesktop+kicker (->no need for
> > > > autostart-after= as that seems to be used for these two only, and
> > > > moreover it doesn't right now really work anyway), phase 1 for parts
> > > > of the desktop and phase 2 for everything else than can wait (you
> > > > don't really need all that systray nonsense immediately).
> > >
> > > Hmmm .... why doesn't it work reliably?
> >
> >  Autostart code handling waits for the app to register with DCOP (or just
> > waits until it's launched, I'm not sure), which happens rather soon in
> > the app's startup process and way before it's actually up and ready.
> >
> > > Is the reason, that we don't know
> > > when the autostart is ready/finished? If this is the reason, then the
> > > phases also won't work.
> >
> >  They do :). Ksmserver has the same problem, as registration with the
> > session manager also happens soon, but kdesktop and kicker have special
> > code to tell ksmserver they're really ready.
> Would it have any crazy size effects to move DCOP registration to being
> done with a single-shot timer so that it happens in the event loop after
> the applications constructor has returned?
> (In JuK I've had to block incoming DCOP calls in the main function to make
> sure that they're not called before the things that they access are
> actually constructed.)

In KAlarm, I have also had to take special measures because autostart 
sequencing doesn't work in a practical way. The problem is that although the 
sequence in which programs are kicked off may be predictable, the order in 
which they are ready for real work is not.

KAlarm really consists of two programs - kalarm and kalarmd (the alarm 
daemon), which need to coordinate with each other (if the user has configured 
both of them to run at all times). Both are autostarted, but kalarm is also 
session managed, and one starts the other. But because the order in which the 
two programs become operational was unpredictable, I had to introduce kludges 
like waiting for half a minute before attempting to access the other program.

Autostart, especially in combination with session management, is really not 
satisfactory currently. For more details, see the thread beginning 
http://lists.kde.org/?l=kde-core-devel&m=112546646931770&w=2 .

David Jarvie.
KAlarm author and maintainer.

More information about the kde-core-devel mailing list