So I went to plan B, which was to reimplement a maemo-specific GUI in python that just talks to a perl back-end which takes care of all of the actual data processing. This is now well under way. A working prototype of the GUI in python is now in SVN, it can read and display calendar data, but has no edit capabilities yet. The back-end portion is just about finished, it is a mixture of code from the dayplanner perl client and the dayplanner-daemon, what’s missing there is more configuration file handling (which can’t be done yet, because I’m not quite sure what config options the maemo UI actually needs) and synchronization code.

This has helped make Day Planner even more modular. I split out some code that is useful elsewhere into a DP::CoreModules module. That module now has code that for instance handles the configuration files, parses date strings, creates config dirs, runtime module loading, summary string wrappers and localtime() wrappers. All code that can be shared (and doesn’t merit having their own module) will be put there.

I expect the maemo port to have initial editing capabilities within 1-2 weeks, depending on my workload.

The gtk2 perl bindings still don’t have a maemo port. I’m going to have a go at those first to see if I can get them running half-decently without too much work, if not I’ll have to look at other more dirty hacks. Though if I can get the bindings themselves running that would be much better and would make the port a lot easier to maintain. Here’s hoping!

The primary focus of this release was getting some new technology in there and cleaning up old stuff.
The daemon (or “reminder” as it is called in the user-facing UI) was rewritten from the ground up. The new one is a lot more flexible, and less error-prone than the old one. The new one can for instance notify users about events backwards in time (say you log in at 08:05 and you had a meeting had 08:00 – it’ll let you know). Along with this I’ve removed the “Day Planner commander”, which was a commandline interface that allowed one to talk directly to the daemon and issue commands. I used it mostly for debugging with the old daemon, it’s not needed at all with the new one. The notifier (the program that pops up friendly GUI dialog boxes with reminders) was also partly rewritten for the daemon change.

The other major change was the addition of DP::iCalendar::Manager. This module allows DP to have multiple DP::iCalendars (and other compatible objects) in one object, whose API is completely identical to DP::iCalendar (with the exception of a few additional methods). In 0.8 it is for instance possible to edit holiday-events. The Date::HolidayParser module now presents a DP::iCalendar-compatible interface when requested (the old API is still in there, and is still the default – that won’t change). As Date::HolidayParser (and for instance http calendar subscriptions) are essentially read-only data sources, DP::iCalendar::Manager handles this nicely. When a change request is made upon an event from a read-only source the manager copies the event over to the primary DP::iCalendar object and makes the change there. This preserves the UID and thus the changed event will show up in the UI, instead of the original one.

All DP::iCalendar calls in 0.8 go through the manager, even though the management part isn’t used much, the only two parts added to it in 0.8 are the primary user calendar and the holidays. This opens doors for what one might expect to see in 0.9. Day Planner 0.9 will. among other things, have support for subscriptions to http-calendars. The current DP SVN already has a crude implementation of this, and it appears to be working pretty well (though it is missing some essential things, like caching, at the moment).

Day Planner 0.8 is available for download as a Mandriva RPM, Ubuntu/Debian deb, generic installer and source tarball.
For the adventurous (read: people who like to not have their software in a working state all the time) there are instructions on how to get the svn version on the website.