Migrating Apps — KAlarm — 2

Part 1: Migrating Apps — KAlarm — 1

I wanted first to focus on massaging or converting the current KAlarm data. While only five dozen events are configured, I do not want to manually recreate the data.

Radicale seemed like a way to centrally store reminder data. There are two challenges. I needed client software to access the data and I do not know the file format of how the data is stored.

I decided to first try Orage. If I could massage the KAlarm data into a different format, perhaps that format would be compatible with Radicale. If successful then Orage could be the needed client software.

A quick import into Orage failed. Comparing the data formats reduced to trial and error. In Orage I manually duplicated some KAlarm events and then distinguished the differences between the two file formats. Eventually I derived a shell script to convert the KAlarm data file into an Orage data file.

Noticeable is KAlarm is missing a SUMMARY category for the parent VEVENT data. Because of the narrowed “reminder” focus of KAlarm, I am guessing the KAlarm code is designed to only use the VALARM DESCRIPTION field. Because KAlarm is stand alone and not targeted to be fully standards compliant, this design suffices. Not great though for exporting the data to a standards compliant app.

An unexpected challenge is I was unable to wrap my mind around the Orage interface. The problem is between my ears. I needed to adjust my conceptions and presumptions. Nonetheless, something does not click. I grew frustrated.

Even if I resolved the interface challenges I had with Orage, I was uncomfortable because like KAlarm, the app is user-centric. While “foreign” calendars are supported to a nominal degree, centrally stored data is not a cornerstone design concern.

This left me looking at ReminderFox.

Interestingly, ReminderFox has been tested with Radicale as a backend or “remote calendar.”

After letting the migration project sit for many weeks, I tried again with ReminderFox.

I hoped ReminderFox would suffice. I had run out of candidates.

While not stand alone, I am likely to have either Firefox or Thunderbird running, and likely both. A caveat to ReminderFox is I have to have Firefox or Thunderbird running all the time to receive notifications. While running one or both throughout the day is likely, the stand alone applet approach makes more sense to me.

With ReminderFox I ran into the same import frustrations. This time I was more determined to put this project behind me. As ReminderFox supports compliant ics files, I repeated the previous Orage experiment by duplicating a couple of KAlarm entries and then comparing the data files.

Apparent to me was that the KAlarm ics file is not standards compliant.

The missing SUMMARY field is the biggest glitch, but deleting some unnecessary KAlarm fields helped reduce clutter such as font color and some kind of SEQUENCE field.

I wrote another shell script to perform the conversion. The shell script was not perfect. I had to perform some preliminary manual cleanup of some long DESCRIPTION fields. That was okay because this was a one-time migration. I do not know perl but some grep, sed, and awk commands created an ics file that ReminderFox imported without quarrel. Even the repeat periods imported correctly.

The ReminderFox design is a tad non standard. First on my irritation list is typical small fonts. I do not know why developers insist on using tiny font sizes. Browsing the docs discovered keyboard shortcuts to increase the font sizes. There are no toolbar icons to modify the font sizes.

There is no OK button anywhere in the import dialogs. The import process stumped me for several attempts. The trick is to select the Import button, select the New button, then the Confirm button, and then the New button. Nutty.

The defaults include a Foxy Icon in the top toolbar. The icon used the space of two icons and distracted me. I removed the icon and use the Firefox tools menu.

ReminderFox is sluggish when opening or working within the configuration dialogs. Probably because of JavaScript, the bane of the world wide web. For example, on my laptop viewing the next month’s calendar layout takes about three seconds to change.

The notification dialog in KAlarm is a simple Information OK dialog. The ReminderFox dialog is designed differently but seems equivalent.

About two hours after I finally imported the data, ReminderFox opened a dialog for me to acknowledge many reminders. The cause is the way the addon is designed. Apparently ReminderFox is designed to track events starting January 1. KAlarm is designed to list events starting from the current day. I think this dialog is a one-time occurrence and should not affect long-term usage. I won’t really know for another year. I have a few events that are annual and biennial.

One attractive feature is the ability to store the data file outside the Firefox or Thunderbird profile or $HOME directories. This feature means I do not need to research calendar servers to centralize the data. This feature might also mean there is no need to investigate Radicale, although I will leave that door open.

Another feature that seems helpful is placing a status bar somewhere within Firefox. I used the right side of the bookmark toolbar.

While not explicitly tested, ReminderFox seems to support concurrent use. I acknowledged a notification on one system and when I started Firefox on another system using the same centrally stored data file, I received no “missed” reminder notifications.

In all ReminderFox seems equivalent to KAlarm with respect to my needs. The acid test is concurrently monitoring both apps for several weeks to observe notifications, missed notifications, deferrals, and repeat periods.

I am hoping with a few possible adjustments as I learn the software, another migration is behind me.

Posted: Category: Usability Tagged: General, Migrate

Next: Tradeoffs

Previous: Migrating Apps — KAlarm — 1