Hiya David. KAlarm has been really helpful for me over the past few years in Linux Mint 17.x KDE4, so i thank you for it. Sadly however i'm having no luck with it in Maui Plasma5 [based on Ubuntu 16.04, & Neon]. It installed ok, but i cannot create any alarms. Each time i do, a frustrating dialog pops up; "Sorry - KAlarm. You must select a calendar to save the alarm in". I don't know how to solve this [Akonadi is running].

Any ideas please? As you'd be aware, KAlarm is much more capable & useful than any other Linux alarm [that i've been able to find, anyway], so losing this tool in Plasma 5 would be highly disadvantageous. I hope you might be able to help please.

KDE Plasma 5.8.3
KDE Apps 16.08.2
Frameworks 5.27.0
Qt 5.7.0
Kernel 4.4.0-57

There is a fix in KDE Applications 16.08.3 for what you're seeing. The problem is that KAlarm does not create its default calendars when it is first run. However, with the version you have, you can get round this by creating the calendars yourself, as follows:

In the KAlarm menu, choose View -> Show Calendars.
In the Calendars pane, click Add. Then choose the storage method - just choose KAlarm Calendar File if you don't care how alarms are stored.
In the dialog which then appears, enter

* Filename: ~/.local/share/kalarm/calendar.ics
* Name: Active alarms
* Alarm Types: Active Alarms

Click OK.

Similarly set up an archived alarm calendar, but with

* Filename: ~/.local/share/kalarm/expired.ics
* Name: Archived alarms
* Alarm Types: Archived Alarms

If you use alarm templates, similarly set up a templates calendar:

* Filename: ~/.local/share/kalarm/template.ics
* Name: Alarm templates
* Alarm Types: Alarm Templates

Hi & thanks David. Unfortunately after doing these steps, KA still responded the same way as i'd originally posted. Also [i do not understand if this is significant or not], when i navigated to ~/.local/share/kalarm/ i saw that such files already did exist. Nonetheless i did apply your steps, which seemed to create duplicates in your GUI, albeit one instance of each conjugate-pair had a Disabled status [per a ToolTip]. Once i discovered that KA still gave that error msg, i then closed KA completely, deleted ALL files from that directory, then repeated your steps. It made no improvement to the subsequent KA behaviour once i tried again to create & save a display-alarm.

Maui Linux gets its Plasma updates from the Neon repo. I wonder which Plasma 5.8.x version will include KDE Applications 16.08.3 -- if i can find that out, maybe then i can ask the Maui Devs approx. when we might get that P update... unless you have alternative ideas on stuff i could try in the meantime?

David -- i have a happier update to advise you now. This was bugging me so i tried it again, & happily now i CAN create, store & use new display alarms in KAlarm in Maui [ie, in a *buntu 16.04 derivative, with Plasma 5.8.3].

I think the reason for the previous negative outcome after trying your steps was twofold:
1. Those ~/.local/share/kalarm/ pre-existing *.ics files i mentioned, were read-only. I noticed that at the time, but failed to grasp the significance.
2. The new files created as a result of your instructions, manifested in KAlarm GUI Tooltips as "disabled", which i incorrectly interpreted as implying these files were defective. In fact, it was simply that they had not yet been selected/activated in the GUI -- doh!

So all i did today was to remove all those calendars, in the GUI, then repeat your instructions, including this time to ensure that those new cals were activated. Thereafter... no more error msg once i created & saved new alarms. Yay!!!

Unfortunately it's not all yet perfect. Every attempt i made to export my existing, good, alarms from one pc, in order to [i'd hoped] import them into KAlarm in my other pc, failed with an error msg... it was unhelpful, saying only that it could not export, but not saying why. Whilst that's not great, my need to export is non-essential, whereas being able to create & use alarms is... hence, on balance, i'm happy.

My thanks to you, David.

I'm glad you managed to get things working in the end.

Am I correct in understanding that after deleting the calendars and then following my instructions to create them again, the new calendar files were read-only? If so, I'll need to fix that, since it certainly shouldn't happen.

As for the export not working, that reminded me that somebody else had mentioned an export/import problem in a comment on an unrelated bug report, which I'd forgotten about. I've now created a new bug report about that (https://bugs.kde.org/show_bug.cgi?id=374337). If you want to be notified when the bug is fixed or updated, please add yourself to the CC list for the bug.

djarvie wrote:I'm glad you managed to get things working in the end.

Am I correct in understanding that after deleting the calendars and then following my instructions to create them again, the new calendar files were read-only? If so, I'll need to fix that, since it certainly shouldn't happen.

No, kinda the opposite, as best i can remember. Once i'd started over again, the new files were not RO, they were simply tooltipped as "Disabled" [which initially i entirely misunderstood as denoting A Big Problem, & only when i came back the second time to try again, did i then realise that status simply meant that they were not yet activated/selected [i'd imagined that the act of creating the new calendars per your method would have also activated them; i was wrong].

The RO ones were those most mysterious pre-existing calendars that i first saw when i began tinkering. Their presence was what bamboozled me. Once i'd deleted them, & reapplied your method the 2nd time [& had more coffee], it came good. Sorry for my muddle.

djarvie wrote:As for the export not working, that reminded me that somebody else had mentioned an export/import problem in a comment on an unrelated bug report, which I'd forgotten about. I've now created a new bug report about that (https://bugs.kde.org/show_bug.cgi?id=374337). If you want to be notified when the bug is fixed or updated, please add yourself to the CC list for the bug.

Nice! Yes i will add myself as suggested.

Thanks again David... for your original work, & for your subsequent support.

Thanks for your clarifications. I think you could reasonably expect that after creating the calendars, they would not be disabled. That's something which needs investigation. In addition, I'll have to look into why the original calendars were read-only - again, that shouldn't happen.

The error saving exported alarms is now fixed, and will be in the KDE Applications 16.12.1 release.

I installed 64-bit Debian 10.4 buster, after discovering the Debian installer doesn't look at your processor and decide what to install -- so I had been using 32-bit Debian buster.

I restored my home directory from a backup.

I started KAlarm. The "New" button in the toolbar, and the "File" menu, are grayed out. I terminated KAlarm.

I backed up ~/.config/kalarmrc and ~/.local/share/kalarm/*, to ~/kalarm.sv, and then removed them.

I started KAlarm. It magically found an old kalarmrc file from somewhere (maybe .kde/share/config/kalarmrc), copied it to ~/.config, and made a few changes. It changed the version from 2.10.3-ak to 2.12.2, and added a [Migratekde4] section with one line "Version=1".

The kalarmrc file mentions a calendar.ics file I have as a backup, and copied that file to ~/.local/share/kalarm.

I tried everything listed here. File permissions are all 644. Directory permissions are all 755.

After View -> Show Calendars -> Add..., there are three files in the "Recent Files" line under [KFileDialog Settings], instead of the two that were in the backup. The new one is the one I specified under ...Add: .local/share/kalarm/calendar.ics. It has all my old alarms.

I terminated KAlarm.

I removed .config/kalarmrc and .kde/share/config/kalarm* and restarted KAlarm.

It created a minimal .config/kalarmrc, with no files listed. It also managed to re-populate .local/share/kalarm.
I used View -> Show Calendars -> Add... to add the files from .local/share/kalarm. This did not change .config/kalarmrc.

In all exercises, after specifying files using View -> Show Calendars -> Add..., if I return to View -> Show Calendars -> Add, there's nothing listed.

I still can't create alarms, or see my old ones.

KAlarm 2.12.2
KDE Plasma 5.14.5
KDE Frameworks 5.54.0
QT 5.11.3
akonadi-server 4:18.08.3-7~deb10u1

I discovered what might have been the problem. There were dozens of copies of akonadi running. When I killed them all and launched kalarm, it complained that akonadi was not running, and asked me whether to start it. I told it to start, and everything works. Except now I have dozens of "active calendar" files. I don't know which ones to delete.

I'm glad it's now working. The issue of having too many akonadi kalarm processes running was fixed in KAlarm version 2.12.5, but with earlier versions of KAlarm such as yours, it is definitely a good idea to remove unnecessary ones because having multiple processes can significantly affect performance.

To do this, first quit KAlarm. Then run the utility akonadiconsole (which you may have to install first). In its Agents tab, select each of the KAlarm resources in turn and remove all the duplicates (i.e. resources which reference the same calendar file). This will not affect your actual calendar files, so don't worry if you remove any that you didn't mean to remove. Then run KAlarm again, and check that the Calendars panel lists all the calendars which you want to use - if not, use the Add button to add them back. There should now be exactly one akonadi process for each KAlarm calendar.

I'd like to clarify a couple of misunderstandings about kalarmrc:

1) kalarmrc is not used to store any details of the calendars which KAlarm uses. That information is stored in KAlarm's Akonadi resources, which each have their own separate configuration files. As far as I know, the only place that calendar file names might appear in kalarmrc are in the FileDialog settings (which you mention), but those file names are solely used by file dialogs to know recently selected files used in dialogs, and are irrelevant for knowing what calendars are actually in use. So your problems don't arise from kalarmrc.

2) After deleting kalarmrc and ~/.local/share/kalarm, when KAlarm was restarted, it would have looked for an existing kalarmrc first in ~/.config, and because that wasn't found, it would have looked in the location used under KDE4, which was (dependent on distribution) typically in ~/share/config or ~/.kde/share/config. This is likely to be why the [Migratekde4] section was added, to record that migration of kalarmrc from KDE4 had been done.

Thanks for the explanation. Consider adding it to the document, maybe in a "troubleshooting" section, so others won't pester you with the same question again.