Ramblings on computers…

Tag Archives: Almanah

I've arrived about a week late to the party, but there are now some shiny new releases of Almanah, Hitori, Totem/totem-pl-parser (with my I'm-Bastien-Nocera hatbeard on) and libfolks for people to use and abuse. (Versions: 0.9.0, 0.3.2, 3.3.92, 3.3.92 and 0.6.8, respectively.) Many thanks to all the people who've done all the work on them this cycle (including all the bug fixing and running around which I was supposed to do; sorry about that).

Why so late? I was busy. University has been keeping my work queue full up for the past few months, and it's not going to ease off until June. Doing all these releases has made me realise what a bad maintainer I am for projects like Almanah. It's used by many people, but has seen few releases recently, and even less development work (basically none of which has been done by me). There's an ongoing plan to modernise its design, and I'm sad that I can't put any time into making this happen.

I'm putting Almanah up for adoption. Wanted: an enthusiastic new maintainer with big ideas for the project's future. It's a reasonably stable project, with a well documented, if a little crusty, code base. There's plenty of scope for new features, and I'll try and guide you as appropriate. Let me know if you're interested! If not, Almanah will continue to limp along as best I can manage.

Dragging its feet behind version 0.5.0 comes version 0.6.0 of Almanah. This release is primarily to improve upon the "link" concept which was present in all previous versions. Now, links have been replaced with the concept of a "definition": terms can be defined across multiple entries, to allow you to go into more detail about something which existed over a longer period of your life. For example, you could define a term for a project on which you'd been working for a couple of weeks, or for a new acquaintance. Currently, only the old link types (note, URI and file) are supported as definition types, but in future, other types will be added, such as Evolution contact.

This release also introduces "events", which are listed automatically per day. Now Almanah will list all the Evolution tasks and appointments relevant to the currently selected day, to provide a little more context for whatever's in that day's entry. Again, more event types can – and should – be added in future.

Apart from these major changes, accessibility and printing support have been improved, and a new --import-mode switch has been added to allow one-time imports of previous diaries without any date-based restrictions on editing entries.

Note that the link/definition/event changes have changed the database schema, and when upgrading to version 0.6.0, all your previous links will no longer be accessible from the interface, and cannot be automatically ported to being definitions. You can, however, retrieve them manually using the following commands:

sqlite3 ~/.local/share/diary.db

.headers ON

SELECT * FROM entry_links;

which will list all your old links as they exist in the database. You should run these commands while Almanah is running, unless you have encryption disabled.

It seems to be release week for me. Here's Almanah Diary0.5.0. Of note with this release is the support for text formatting (bold, italic and underline — nothing particularly fancy), persistent window dimensions, the ability to set the encryption key, and better recovery from database corruption/errors (although it's still not perfect).

Packagers should note that the GTK+ dependency has been bumped from 2.12 to 2.14, and the GConf dependency is no longer optional — though the GtkSpell dependency now is (as spell checking support is now optional).

Automatic link types (yes, this is a stupid name), so that (for example) past Evolution appointments would be shown for each day

Documentation

Export to blog, text file, HTML, etc.

Undo/Redo support

The first three are what I'd like to definitely get done for 0.6.0, but before I can do that I need to sort out the naming for "links" and "automatic links". Obviously these are rubbish names, especially considering one can currently add a "note link". I had considered "attachments", but that's not much better. Does anyone have any ideas?

The time has finally arrived, and I'm off on my travels in four days. I'll be away from the computer for up to two months, spending a month trekking in Chile, then a month doing various other things. I might be back in time for the GNOME 2.24 string freeze, but I should definitely be back in time to see the release. In my absence, I obviously won't be able to do any further work on this cycle, but I think all my current contributions are pretty much complete anyway. I won't be replying to mail for at least the period I'm in Chile.

I won't be around to see them get into the archives, but Stefan Ebner has been working on packaging both Diary (now called "Almanah" due to Fedora issues) and Hitori for Ubuntu. My thanks to him for his hard work on that, and patience in helping me fix all the nasty little autofoo problems.

I'll try to make an Almanah (Diary) 0.4 release before I go, but I want to leave as long as possible for translations to catch up with the several string changes.Almanah 0.4.0 is out! The main change for this release is to rename it and fix some problems preventing it being packaged, and so it should be compatible with old databases. The build requirements haven't changed.

Using my exam leave productively, I've tidied up and released version 0.2 of my diary editor. This version fixes the crash some people were getting with version 0.1, and introduces database encryption and printing support.

The new version should seamlessly upgrade plaintext databases to encrypted ones, and uses the key from /desktop/pgp/default_key in GConf. If you don't want encryption support – perhaps, for example, as it depends on GPGME – you can compile with --disable-encryption.

The printing support allows you to print the entries in a specified date range in a simple format — nothing suitable for binding for posterity's sake, unfortunately. It's there nonetheless.

Get the Bazaar branch from my website with bzr branch -r tag:V_0_2_0 http://tecnocode.co.uk/diary, from Launchpad, or download the tarball!

I've been keeping a personal diary for a while, but recently I've found that my previous storage method for it – keeping each day's entry in a separate file, stored in a folder hierarchy – was getting too unwieldy. That's why over the last few weeks I've written a small program to manage a diary.

I initially started writing it in Vala, but I found that I was having to put in dirty hacks every couple of tens of lines just to get the simplest things working with an SQLite database. Either due to my own lack of knowledge of Vala, or teething problems for the language and its bindings, I couldn't get it to work, so about a week ago I scrapped it and ported the program to old-fashioned C.

So here it is: version 0.1 of my diary program. It supports basic editing of diary entries, a calendar view of the month and the ability to add "links" to each entry. A "link" is something which connects the diary entry to the wider world, much like a hyperlink connects one web page to another. At the moment only "URI", "file" and "note" link types are supported, but in the future I plan for one to be able to link to anything from an F-Spot album to a section of a chat log in Empathy. Such links would allow references to conversations, e-mails, photo albums (etc.) in diary entries to be easily followed to find the goodies mentioned.

I also have plans to add Evolution calendar integration, as well as potential integration with Mugshot. It would be nice to see diary entries which can show all of what happened on that day, from doctor's appointments in Evolution to the songs Mugshot says you listened to.

Keeping my feet more grounded in reality, however, I think the next thing on the agenda is encryption for the database the diary uses, so your darkest secrets aren't so easily discovered.

To get it, you can either download the tarball or get the latest bzr tree from my website using the following command:

bzr branch http://tecnocode.co.uk/diary/

Thanks to people in the comments for pointing out a better way of branching.

The only requirements are gtk+-2.0 >= 2.12, sqlite3 and gtkspell-2.0, and it's built in the usual fashion.

Feedback is welcomed warmly and given somewhere to stay for the night.