The release focused primarily on fixes and cleanups. A bunch of minor bugs were fixed, and I rewrote most of the iCalendar back-end. It should be faster now and preserves files better than it used to.

This release includes a dummy maemo interface. It can currently fully display a Day Planner calendar, and has a UI quite similar to the desktop edition. However, it can not edit or add any events, and is as such not as useful as it might have been. The plan is for the maemo port to be ready for 0.11.

0.10 will (among other things) feature a new HTML exporting module (which has been in the works for quite a while), a cleaner, object-oriented version of the add/edit event windows (to simplify their use and maintainance. The current code that handles it is a bit ugly).

The major user-facing change will be the addition of a GUI for calendar subscriptions. 0.9 includes support for them (though it isn’t really announced because the feature isn’t ready), but one has to manually edit the config file.

In other related news, I’ve just released a development snapshot of Day Planner 0.9.
It is available at http://www.day-planner.org/index.php/download/devsnapshot. It contains all of the developed features for 0.9 (including the unfinished maemo port), but is not yet stable enough to be labelled stable, so If you’ve got time and feel like it, give it a spin and report any bugs you find. The whole iCalendar back-end has been almost completely re-written for this version, which is why I want some additional testing before I release a stable version.

Please do not package this release or submit it to news sites, it’s just a svn snapshot.

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.

I’ve been picked as one of the lucky 500 that will recieve a Nokia N810 at a heavily discounted price.

My initial plans will be to investigate ways of porting Day Planner to maemo. Because there are no Gtk2 perl bindings for Maemo at the moment, as far as I know. I’m going to have a look at how hard it would be to port the current Gtk2 perl bindings to Maemo, and if it’s rather simple I’ll just bundle them along with Day Planner., or create a package for them. They might even run with little effort, who knows (heres hoping). Even if they don’t work 100%, as long as the methods DP uses work adequately I will be able to use them. If not, well, then I’ll have to look at other options, which include writing a dumb UI in python that talks to a perl-backend.

In any case I will need to figure out how to best integrate the daemon+notifier functionality. The platform probably needs its own notifier, if it is to have such a thing at all, though I’m hoping the daemon can work without major changes.

And now I just need to wait for it to be released so I can get it.

Creating a deb was interesting, as I had never done that before – used to rpm packaging, though I got a lot of help by Morten Werner Olsen.

The packaging also uncovered quite a few limitations in both the default tarball and the Makefile, which should not only make the deb possible, but also improve the RPM.

I’m hoping to get Day Planner into Debian too, but I’ll have to write a proper deb for Date::HolidayParser first. Debian, like Mandriva, wants to have modules available as seperate packages, and as Date::HolidayParser isn’t *really* Day Planner-specific it makes sense distributing it seperately. The current debs has it bundled, and I might be inclined to continue to have the ones on the website bundle the module (the RPMs on the website does this, even though the package in Mandriva does not), so that there is only one package to install to get Day Planner installed.

In other (somewhat) related news, I’ve changed the URL structure on the Day Planner website. It previously used ugly looking index.php?page=foo&type=bar URLs. It now uses clean index.php/foo/bar URLs, which incidentally was rather simple to implement once I found which variables to parse and PHP functions to do it with.

If it’s been a while since you tried it, or if you haven’t tried it at all, go ahead and give it a download. It is available as a Mandriva Linux noarch RPM, generic .run installer and a source tarball, it also has only one single dependency except for perl and that is the gtk2 perl bindings, so it should run without having to install 20 dependencies.

Here’s an abriged changelog:
A bug that caused the entire program to go insensitive if you clicked the edit button without having any event selected was fixed. Daemon errors are handled better. A bug where day planner would freeze if the daemon shut down while it was running was fixed. Localization was fixed. A Norwegian bokmål translation was added. The pop up dialogs is now placed on top of the main window. The notifier now gets the information from the daemon instead of getting it on the command-line, so that other users can’t see information about other users on the system.

I would still very much like any comments you might have, so please feel free to test and give feedback.