Session restoration and autostart

[Christian Esken]

Am Montag, 5. September 2005 01:19 schrieb 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. 

That is an interesting observation. Thanks for digging this up. This could 
also be the reason for KMix showing up on the desktop of some users on 
*every* Login. The bug https://bugs.kde.org/show_bug.cgi?id=58901 would then 
be triggered like this:

- KMix Autostart : does not show KMix main window
- KMix Restore : The KUniqueApplication KMix sees, that an instance is already 
running and explicitely calls show() to show its Main Window => Bug 
triggered .


Possibly I could add an extra isRestored() check:  
- if ( m_kmix )    /*there-is-an-instance-running*/
+ if ( m_kmix && !isRestored() ) /*there-is-an-instance-running */
{
    m_kmix.show()
} 

But I don't know wheteher this will work. I also believe this is only a 
workaround, and that there is something low-level broken, because I got very 
strange comments on workaround for the noted bug, e.g.: "I noticed that it 
docks well when no netwrok connection is active"

  Chris