Bug 1610

Correction: about 40 seconds as observed with a stop watch.

Clarification: A reboot of the computer is not required. Just restart Trinity.

Notes: When I disable kalarm autostart, the kalarmd still autostarts as expected. When I wait for the Trintiy startup to stabilize and then manually start kalarm, the app starts immediately.

The kalarmd autostarts early in the Trinity startup.

In kalarmapp.cpp:1013, there is a comment discussion about a timer delay with the system tray icon. I don't know whther that is related.

Tim, could this bug be resolved with the same type of patches submitted July 7 and 8 related to an oversized tray icon?

While kalarm was not directly affected by those patches, it is conceivable that one or more malfunctioning tray applications disrupted other normally functional tray applications.  I observed this on my test system, but didn't put two and two together until several applications started to abort on startup due to the ridiculous (2kx2k) icons being posted to X.  In particular, korgac was hanging, causing kded to become unresponsive and causing a complete mess.

Darrell, can you see if you are still affected by this bug with the latest R14 sources?

Thanks!

>can you see if you are still affected by this bug with the latest R14 sources?
I'll post information the next time I build a package set.

>can you see if you are still affected by this bug with the latest R14 sources?
The recent slew of patches have no effect on this bug report. KAlarm still opens a long time after starting the Trinity session.

While testing TDE apps in the MATE desktop, I noticed that while the kalarm icon became available in the MATE system tray immediately, a StartupNotify icon appeared in the MATE panel for the kalarm daemon. Seems then perhaps the long initial startup delay is actually the daemon. I don't know why the kalarm icon appears immediately in the MATE system tray despite the daemon not yet starting and in TDE the icon does not appear for about 30 seconds after starting TDE.

Created attachment 2453 [details]
Proof-of-concept patch to remove kalarm autostart delay

>Seems then perhaps the long initial startup delay is actually the daemon.
Looks like the root cause is hard-coded in tdepim/kalarm/kalarmd/alarmdaemon.cpp:52:

static const int KALARM_AUTOSTART_TIMEOUT = 30;

The timeout coincides with my original report that the delay is about 30 seconds.

The source code comments for that constant:

// Number of seconds to wait before autostarting KAlarm.
// Allow plenty of time for session restoration to happen first.

While I accept that in the early days of KDE development such a delay might have been needed, I doubt this delay is necessary any more in TDE.

I am attaching a proof-of-concept patch that reduces the delay from 30 seconds to 1 second. I did not delete the delay entirely or set to zero. I'll let the threading and autostart experts decide whether any delay is needed.

The patch resolves the delay problem for me as originally described.

Created attachment 2521 [details]
Change autostart delay from 30 to 3 seconds

Apparently something changed the past few months that affects the original proposed proof-of-concept patch (attachment 2453 [details]). While the patch worked fine when proposed in February, the latest result as of June 14 is KAlarm will not autostart. Refer to bug 2458 for those details.

Attached is a new proposed patch that does not remove the delay mechanism but only changes the delay to 3 seconds.

There is another work-around to the 30 second delay. Rather than use the KAlarm autostart mechanism, place a copy of the kalarm.desktop file in ~/.trinity/Autostart.

Created attachment 2538 [details]
Change autostart delay from 30 to 1 second

There is a reason why the 30 second delay was introduced (see comments @ kalarm/kalarmd/alarmdaemon.cpp:76-85).
I shall see if I can find a smarter way to manage both autostart and restore requests that do not required a fixed waiting time.

The proposed patch from Darrell should *not* be pushed, since although effective in many cases, it may lead to double KAlarm windows showing up in some other cases.

Comment on attachment 2538 [details]
Change autostart delay from 30 to 1 second

Marked obsolete and should not be pushed (see previous comment)

Patch is available. It will be pushed after R14.0.1 is out.

KAlarm can be either restored by the session manager or autostarted by the KAlarmDaemon. The 30 seconds delay in the original KAlarm code was introduced to make sure that the session restoration was done and completed before autostarting KAlarm from the daemon, otherwise KAlarm restoration would not have worked correctly and only a new window would have been open.
The patch changes this behavior as follow. When the daemon is started, it checks with the session manager whether the session has been fully created/restored. If not, it waits 1 second and try again (up to 30 seconds max). If the session has been fully created/restored, it waits an additional 3 seconds (just to make sure the restored programs are up and running) and then autostart KAlarm in the system tray.
So in general KAlarm gets started about 3 seconds after the session has been created/restored. This should be fast enough, I hope.

Forgot to say, this patch will *not* be introduced into the R14.0.x series

Fixed in commit c2ad4a05.

Correction: fixed in commit c2ad4a05 (tdepim) and b45b9ed (tdebase).