Summary: | Alarms don't appear until KAlarm is run manually | ||
---|---|---|---|
Product: | [Applications] kalarm | Reporter: | Christian Roerecke <christian.roerecke> |
Component: | general | Assignee: | David Jarvie <djarvie> |
Status: | CLOSED FIXED | ||
Severity: | major | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Christian Roerecke
2003-01-06 11:49:17 UTC
What version of KAlarm and KDE are you using? Subject: Re: Alarm events bind to a session rather than a user On 6 Jan 2003 software@astrojar.org.uk wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=52659 > > > > > ------- Additional Comments From software@astrojar.org.uk 2003-01-06 15:38 ------- > What version of KAlarm and KDE are you using? > I'm sorry. KDE from cvs HEAD some days ago and kalarm from the 22nd december (cvs). There was an important fix which was committed on 3rd January which might fix your problem. Please update your sources and test it out again. For your information, alarms do not bind to a session. So the problem must lie elsewhere. Subject: Re: Alarm events bind to a session rather than a user Hi, compiling took a while, I own a slow computer. Kdelibs and kdebase as well as kdepim from yesterday. Logged in a few seconds before 11:47 I do not get alarms displayed until I start kalarm manually. These lines are still in my logs: libkcal: CalendarLocal::appendAlarms() '': Die Dez 17 15:19:54 2002 libkcal: CalendarLocal::appendAlarms() '': Die Dez 17 15:17:38 2002 libkcal: CalendarLocal::appendAlarms() '': Die Jan 7 11:47:00 2003 kalarmd: AlarmDaemon::notifyEvent(KAlarm-705227045.279) kalarmd: appName: kalarm notification type=2 kalarmd: AlarmDaemon::notifyEvent(): wait for session startup kalarmd: AlarmDaemon::notifyEvent(KAlarm-1888164697.212) kalarmd: appName: kalarm notification type=2 kalarmd: AlarmDaemon::notifyEvent(): wait for session startup kalarmd: AlarmDaemon::notifyEvent(KAlarm-2116494565.816) kalarmd: appName: kalarm notification type=2 kalarmd: AlarmDaemon::notifyEvent(): wait for session startup What does notification type=2 mean? Am I using kalarm in the wrong way? This has nothing to do with reccurence, right? Christian Looking again at your report, I realise that the recent KAlarm fixes aren't relevant to the diagnostics listed in your report. Am I correct in thinking that KAlarm didn't start at session startup when these messages were logged, and that only when KAlarm was finally run sometime later did the alarms appear? If so, this points to two possible problems: 1) Why didn't KAlarm start at session startup? Perhaps you have disabled automatic start of KAlarm - please list your kalarmrc file (you can find it in .kde/share/config/ or similar). 2) Even if KAlarm didn't start, it looks as if kalarmd should have started it. But this should only happen after the the following diagnostic line is logged: kalarmd: AlarmDaemon::checkIfSessionStarted(): startup complete Please check if this line was output before the lines listed in your bug report. Sorry, but I didn't see your last posted message before posting my last message. "notification type=2" means that the alarm daemon should start KAlarm if it isn't currently running, when an alarm is due. It has nothing to do with recurrence. Subject: Alarm events bind to a session rather than a user Attached my kalarmrc. I was under the impression that I would get notified of alarms no matter what kalarm settings I have applied as long as kalarmd is running. Is that not correct? | Am I correct in thinking that KAlarm didn't start at session startup when | these messages were logged, and that only when KAlarm was finally run | sometime later did the alarms appear? Yes, that's right. kalarmrc: [Defaults] DefBeep=false DefConfirmAck=false DefLateCancel=false DefRecurPeriod=0 [EditDialog] Height 768=482 Width 1024=620 [General] AutostartTray=false ConfirmAlarmDeletion=true DaemonTrayCheckInterval=10 DisableAlarmsIfStopped=false MessageBackgroundColour=255,0,0 MessageFont=Arial [Monotype],16,-1,5,50,0,0,0,0,0 RunInSystemTray=false Sod=-2109401552 StartOfDay=1900,1,1,0,0,0 [KFileDialog Settings] Recent Files=/opt/kdecvs/share/sounds/KDE_Beep_RimShot.wav [KFileDialog Speedbar] Speedbar IconSize=32 [MainWindow] Height 768=307 MenuBar=Enabled Width 1024=512 [MainWindow Toolbar mainToolBar] Hidden=false IconSize=22 IconText=IconOnly Index=0 NewLine=false Offset=0 Position=Top [MessageWin] Height 768=175 Width 1024=240 Just for the record my kalarmdrc: [General] Autostart=true CheckInterval=1 Second question: log: kalarmd: AlarmDaemon::checkIfSessionStarted(): startup complete DCOP: register 'ktip' -> number of clients is now 32 DCOP: register 'anonymous-1479' -> number of clients is now 33 libkonq: ## loaded: 500 entries. DCOP: register 'kalarmd' -> number of clients is now 34 DCOP: unregister 'kalarmd-2' DCOP: register 'anonymous-1480' -> number of clients is now 34 kalarmd: kalarmd:AlarmApp::newInstance() DCOP: unregister 'anonymous-1480' kdeinit: PID 1480 terminated. A hidden crash? Does not seem to be the case: christian@roehre:~> ps aux | grep alarmd 500 1454 0.0 3.1 19752 8096 ? S 11:46 0:01 kalarmd -session 117f000002000104037808700000208000006_1040401792_701278 500 18263 0.0 0.2 1768 696 pts/9 S 12:31 0:00 grep alarmd What next? If in the Preferences dialog you select "Run continuously in system tray" and also "Disable alarms while not running", you won't get any alarms while KAlarm is not running. In all other circumstances you should get alarms, provided the alarm daemon is running. Your kalarmrc file shows that KAlarm will not start automatically at session startup, but it also shows that you *should* be getting alarms regardless of whether KAlarm is running at the time they become due. So there is a fault. I think that I can see in the code why it is happening, so hopefully there will be a fix very soon. As for the "hidden crash", someone else has just reported that kalarmd is activated twice at session startup. The second activation will automatically exit, which is presumably what you are seeing. This should not cause any problems other than to slow things down a little at startup. I hope to fix this also. Fixed in CVS by mods to kalarmd/alarmdaemon.h and kalarmd/alarmdaemon.cpp. The "hidden crash" should have also been fixed by a mod to kalarmd/alarmapp.cpp. Fixed also in KDE 3.1.0. |