KAutoStart

[Scott Wheeler]

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.)

-Scott

-- 
I believe that a scientist looking at nonscientific problems is just as dumb 
as the next guy. 
--Richard Feynman