Session restoration and autostart
Christian Esken
esken at kde.org
Mon Sep 5 11:29:22 BST 2005
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
More information about the kde-core-devel
mailing list