Lightning Calendar Data — 1
One of the long shot goals with migrating to KDE and TDE is using a reminder tool that is not integrated or tied to an email client.
For some years here personal reminder data has been prisoner of the Thunderbird Lightning calendar tool. Lightning stores calendar data in a sqlite database rather than an
*.ics file. Storing data in
*.ics format rather than a database means the file is portable and can be edited directly. Contrarily, the Mozilla style guide seems to be, “Thou shalt ignore simplicity and not use text files to store data when a database can be used.” While special tools allow browsing the database, for most users there is no simple way to directly access the data as is possible with an
*.ics text file.
Personal email volume no longer requires continually running an email client throughout the day. Yet the reminder data has not diminished and is needed continually. Launching an email client to access reminder events is clumsy.
For privacy reasons launching Thunderbird in the house network is impeded intentionally unless connected to a VPN. That means access to the reminder data also is impeded.
Exporting the Lightning data into a clean
*.ics file that can be imported into the KDE or TDE version of
KAlarm seems palatable to achieve that elusive goal of a stand alone reminder tool.
Exporting the data was tried previously. The effort did not go well. A related bug report seems to provide potential clues. Apparently the export problem was a regression introduced by a patch. The problem seems to have appeared after Thunderbird version 60.7.2 and Lightning version 18.104.22.168. A proposed patch seems to indicate the problem was resolved in Thunderbird 78 and subsequent versions.
Despite a long hiatus from TDE, the original TDE profile directory never was deleted. There always was a kind of intuition — or hope — of one day returning. There remains KAlarm data, albeit many years old and outdated. That plain text
calendar.ics data file allows studying and comparing the exported file from Lightning.
To be fair, part of the export data mangling likely is caused by migrating from KAlarm to ReminderFox and later from ReminderFox to Lightning. The original KAlarm is supposed to be compliant with the RFC2445
*.ics format, but uses additional non-standard fields. Possibly those extra fields contributed to the mangling. Then there was the additional layer of ReminderFox with more non-standard fields.
The exported Lightning data contains remnants of those ReminderFox non-standard fields. Although adequate, ReminderFox never was an ideal solution because like Lightning, the data was tied to either Firefox or Thunderbird and was not independent.
A recent test of importing the original KAlarm
calendar.ics file directly into Lightning failed with every event not having a description. The likely cause is KAlarm using only a
DESCRIPTION field and not a similar
SUMMARY field. Conversely, exporting the Lightning data results in bogus
DESCRIPTION fields that do not import nicely into KAlarm.
The exported Lightning file contains stale events. Those events do not appear in the actual Lightning user interface. “Vacuuming” the database does not purge the events.
Importing the exported Lightning data into TDE KOrganizer does not result in any stale or duplicate events or missing event descriptions. Sadly, exporting the data from KOrganizer and importing into KAlarm provided the same results as directly importing the Lightning data to KAlarm. Thus the stale and duplicate data remained in KOrganizer but ignored. Although the KOrganizer import was smooth, the ReminderFox and default Mozilla descriptions remained intact although not used. Odd that with both tools the unnecessary data is not scrubbed.
There also is an exported
DURATION field error:
X-LIC-ERROR;X-LIC-ERRORTYPE=PARAMETER-VALUE-PARSE-ERROR:Got a VALUE parameter with an illegal type for property: VALUE=DURATION
That exported field error does not seem important. There seem to be respective
TRIGGER fields in each event. That malformed field likely was introduced with the original KAlarm or ReminderFox.
The exported Lightning data has more than nine dozen reminder events although a few of those might be duplicate or stale events. Some sweat equity will be required to massage the data into KAlarm.
One caveat is migrating to the TDE version of KAlarm means using a file format that has additional non-standard fields that are not
*.ics standards compliant. Should the need arise to return to Lightning or use a different reminder tool, KAlarm offers no export function, probably because the data file is supposed to be RFC2445 compliant despite the additional properties. That might be the price to pay to have a standalone and portable reminder tool.