KAlarm is the only system-tray service that I have that pops up it's window on boot every time - and that includes other KDE apps such as Amarok, KTorrent and rsibreak not to mention volume control and other system services that also feature a full window in one form or another. This is more a nuisance than a serious bug but it would be nicer if it either opened up on tray only on remembered it's last window's state like Amarok and KTorrent do. Other than that KAlarm is great! It's the best reminder tool I have found for Linux if you don't need a full calendar suite - plus it's KDE, with all the benefits that entails like global shortcuts and superb quality! It's actually the only program I need for PIM as far as dates are concerned, and that's saying a lot :) Thanks for the great application! Reproducible: Always Steps to Reproduce: 1. Install KAlarm. 2. Boot up the system and a KDE user session on which KAlarm is set to open up automatically. Actual Results: A KAlarm window will open up with the KDE session every time. Expected Results: No window to pop-up unless it's the first time KAlarm is ever opened or if it had a window open last time it was closed. It would also be just as fine instead for KAlarm to have a setting "open to tray only" which would need to be manually set by the user. I'm reporting this as a minor bug instead of a wishlist item because it's actually a usability/interface issue, even if it's very minor.
Can you please quit KAlarm (using menu item File -> Quit when there are no alarm windows visible), and then start it using the following command: kalarm --tray Does this start KAlarm with the main window visible, or does it only appear in the system tray?
kalarm --tray makes it initialize without the main window, as you would expect. I have closed kalarm and ran it both with and without --tray to make sure it was working properly. This is such a minor issue, as I said that I won't even bother to disable the current application auto-startup and set up a script with kalarm --tray - but if it would be a simple thing to code in I think it would help bring the application into the highest level of quality, which KDE 5 is headed for! Thanks again for the great app!
Typos made my last comment barely understandable so to clarify: --tray works fine but anyway it would be nicer to have kalarm behave more like the other apps I mention or offer a "open to tray" user setting. Thanks again for the great app!
After logging in, in a terminal window, please type the following command and report what it outputs: ps -ef|grep -w kalarm If its output includes "kalarm -session" followed by a long string of letters and digits, type the following and report what it outputs: grep HiddenTrayParent ~/.kde/share/config/session/kalarm_XXXX where XXXX is the long string following "kalarm -session".
Change status to NeedsInfo
Hi David, the command you asked me to run only shows a running "kalarm" (no arguments). The reason for this is that I am using a startup script that runs kalarm like that from ~/.config/autostart-scripts/ . I am really sorry not taking note of that earlier since it would have been trivial for me to just add the --tray option to the script but it was something I had done when configuring this computer at first and I forgot about it. I also saw that the "start at login" option was checked so i thought this is how kalarm was being launched. This shows an underlying bug though: the only reason I had to create the script is that even though the "Start at login" box is checked KAlarm is not being initiated unless I have my script run. It will be easy for me to just add the --tray option to my script and close this issue but let me know if you want me to open another bug for the "not starting up" issue and I will be happy to run any tests that could help you identify and resolve it.
Thanks. In order to let me diagnose the problem, can you please temporarily remove the startup script, and quit kalarm (using menu File -> Quit) before you next log out or shut down. After you log in after that, do as I asked in comment 4. You can then reinstate your startup script if you want.
The command you asked me to run shows no kalarm instances when I disable my startup script. I have verified that most of my KDE applications are running from my startup scripts - is it possible I am missing a KDE component? This is sounding like it could be a Debian issue since I don't usually install kde-full (the package that installs every single KDE module). Funnily enough klipper is starting up correctly without needing a script, according to the preferences I set when exiting the program (and I mean the application not the klipper widget). I am starting a new session with every new login (instead of saving or resuming sessions) but I imagine kalarm's "launch at login" option is supposed to work like this anyway. Other thing I noted is that even when I disable the "start at login" option the next time I run kalarm it comes up as checked, as if I didn't alter it. The other options seem to be stored correctly after a change though I didn't test this extensively.
The file /usr/share/autostart/kalarm.autostart.desktop should start KAlarm at login, provided that in KAlarm's config file (~/.kde/share/config/kalarmrc or ~/.config/kalarmrc or similar), the AutoStart entry is set to true. I also run Debian, and it works on both wheezy and jessie. Can you check whether the autostart desktop file exists, and if so, whether it has executable permissions set. Also check kalarmrc to see that the AutoStart entry exists in the [General] section, and what its value is. Note that you can disable "start at login" in KAlarm so that it doesn't run at login, but as soon as you run it manually again, it enables "start at login" to ensure that it will always trigger alarms which the user may set up. The reasoning is that it's better to be safe and assume that the user intends to keep using it, and thereby ensure that alarms will trigger, rather than allowing the user to unintentionally not enable it and then wonder why alarms don't trigger.
All files are present and seem to be OK. I have found an issue though. if I run `kalarmautostart kalarm --tray` manually after closing my running instance of kalarm then nothing happens, the command just seems to hang in the command line and kalarm never opens. Could this be why ikalarm is not opening up at startup unless I have a custom script running?
That would certainly explain why kalarm doesn't start. I'll need to think of how kalarmautostart's hangup can be investigated.
I forgot to say that kalarmautostart is designed to hang for 30 seconds before starting kalarm. Please confirm whether it hangs for longer than that.
It hangs for what is probably 30 seconds then exits with an error before terminating: kalarmautostart(14710) AutostartApp::slotAutostart: No command line kalarm is not open afterwards.
It's definitely a bug getting that error message after typing 'kalarmautostart kalarm --tray'. I won't be able to investigate for a week or so, but I'll look at it after that.
The reason for the bug appears to be that Debian testing contains a mixture of KDE Frameworks 5 (KF5), Plasma 5 desktop and KDE 4 applications (including KAlarm). The KF5/Plasma 5 combination doesn't correctly handle autostart of KDE 4 applications. Once Debian testing is updated to contain the KF5 version of KAlarm (in KDE Applications version 15.08 onwards), autostart should work correctly again. KAlarm's KDE 4 autostart configuration is held in ~/.kde/share/config/kalarmrc, whereas KF5 looks in ~/.config. However, even copying kalarmrc into ~/.config didn't make autostart work for me, so there may be some other incompatibility as well. I'm therefore closing this bug as "downstream", since the latest version of KAlarm (in KDE Applications 15.12) already works, and it's Debian which needs to be fixed by updating KAlarm. You could report this bug on the Debian bug system - I don't know whether or not Debian stretch is intended to be eventually released with KDE Applications 15.08 or later.
As I said before I though this could be the case. Thank you for your help and sorry for the mix-ups again. I will forward this to Debian.