Session restoration and autostart

[David Jarvie]

On Friday 02 Sep 2005 12:09, Waldo Bastian wrote:
> On Tuesday 30 August 2005 23:34, David Jarvie wrote:
> > Currently, session restoration and autostart are not compatible for a
> > KUniqueApplication, since there is no guarantee that the application will
> > be activated by session restoration before it is autostarted. If it is
> > activated by session restoration after it has been autostarted, it cannot
> > detect that it is supposed to restore the session.
> >
> > Although in general applications only need to use one or other of these
> > facilities, there can be a need to use both - as in the case of kalarm.
> > It needs to ensure that it is started in the system tray at login,
> > regardless of whether the session is being restored or whether it was
> > still running at
> > logout. But it is also desirable that it should act in the same was as
> > any other KDE application when the session is restored, i.e. that any of
> > its main windows are restored if they were visible at logout.
> >
> > I can see a few ways of addressing this problem, where an application is
> > configured to be both restored and autostarted. In decreasing order of
> > preference for the application developer:
> >
> > 1) Provide a means to guarantee that autostart will only occur once the
> > application has been restored (if it actually is scheduled to be
> > restored).
>
> > This would allow the application to be configured to use both methods
> > without having to take any special precautions.
>
> That's what we have the different autostart phases for already.

Yes, I know - I was involved in implementing them. But unfortunately they 
don't (any longer) work. I use autostart phase 2 for kalarm, but it is often 
autostarted before session restoration. It happens to me on KDE 3.4.1/2, and 
others have reported it on KDE 3.4.0. My assumption in writing my last email 
was that the actual order in which program activations occur is not entirely 
predictable - that it can differ from the order in which the activations were 
initiated. If that assumption is wrong, then it may only be a bug which has 
been introduced in ksmserver for after KDE 3.3, rather than a design problem.

> > 2) When the application is activated to restore the session, provide a
> > means for it to detect that it is being restored so that it can take the
> > appropriate action.
>
> KApplication::isRestored() provides that information.

KApplication::isRestored() only returns true if the first instance of the 
application is started by session restoration. If it has previously been 
started by autostart, KApplication::isRestored() always returns false even 
during the session restoration invocation.

> > 3) Use another autostarted task to "auto"start the application. That task
> > would allow an arbitrary period of time to elapse, in the hope that
> > session
> > restoration will have occurred, before starting the application. (But of
> > course, what is a safe length of time?) Or alternatively, if that task
> > was provided with the means to detect whether the application was
> > scheduled for
> > session restoration, it could then know whether it actually needed to
> > start the application or not.
> >
> > I don't know what the practicalities are of addressing this issue - I'm
> > willing to spend some time on it given some guidance.

Cheers,
-- 
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/linux/kalarm.html