Using Tomboy as a Personal Information Manager

Integration with Evolution, draft 3

Table of Contents

  1. Introduction
  2. Rationale
  3. Case Study
  4. Use Cases
    1. What do we do today?
    2. Let's play well together
    3. On the go
  5. Concepts
    1. Note of the Day
    2. True Tasks and Appointments
    3. Evolution Integration
    4. Tomboy vs Evolution?
  6. Technical Discussion
    1. Scope and Design
    2. Current Work
    3. Synchronization
    4. Unmanaged Tasks
    5. User Input
  7. Deliverables
  8. Where to go from here?
  9. Timeline
  10. Changelog
  11. About Me


Tomboy is a very simple Gnome application for taking notes and keeping tracks of different things. Just recently it has been released with the popular 'Note of the Day' feature, wherein one can jot down tasks and appointments on a fresh note every day. However, there is no easy (and standard) way to micromanage these items, and no way to have all these inscribed information integrated with the other main Personal Information Management (PIM) software on Gnome desktops, Evolution. In most cases, users sacrifice one over the other. In worse cases, one may use both together... and then forget where their data has been entered into! This proposal aims to resolve this dilemma by integrating Tomboy with the Evolution data server to support tasks, appointments as well as basic notes.


Users really want an easy-to-use application on their desktop that allows them to conveniently access their tasks and appointments. All in one place, with minimum GUI interaction, yet complex enough to do everything taken for granted just right. Tomboy is already a popular desktop application that we frequently use. Let's up its usability another notch.

Case Study

As a short case study on how regular Linux users may be using Tomboy I created a poll on the Ubuntu Forums (chosen specifically because it has been attracting a large number of users new to the Linux Desktop concept), accessible here:

Key observations related to this proposal:

  • Out of 58 votes a staggering 29% were negative votes.
  • Almost all of 41 Tomboy users who voted positively use it just for what it has been designed for: as a simple repository for storing arbitrary amounts of text.
  • At least 1/3 of the voters exclaim that they are avid users of Tomboy.
  • At least 1/2 of the voters use Tomboy to keep track of either items, contacts and grocery lists.
  • 4 voters use it as a diary/blog.
  • Less than 1/3 of the voters use it for daily planning, with one user mentioning Evolution's GUI (see Concepts) and Tomboy's lack of task organization features.

Conclusion: Tomboy still needs a great deal of improvement. If some sort of task / planning feature gets implemented in Tomboy more users will be attracted by its ability to more efficiently store and manage their personal information, while users who already actively use Tomboy will immediately benefit!

Use Cases

This proposal covers 3 conceptual use cases: a user that mainly uses Tomboy for tasks planning ('What do we do today?') to demonstrate basic usage for such an application; a user that uses both Evolution and Tomboy ('Let's play well together'), showing how Tomboy integrates with Evolution using evolution-data-server (EDS) as a backend with the ability to synchronize user data; and finally a user on a generic portable device ('On the go'), highlighting how ease of use can be achieved with this application even on minimal-featured systems. For details on what the users are doing, please refer to "Concepts".

What do we do today?

Alice regularly uses the Note of the Day feature for planning out her day. In the morning she opens up the Note of the Day and immediately sees tasks and appointments she has added previously for this day. After scanning through it she adds more to her 'Tasks' list, elaborating on it if required ("Call Bob" with "Forward client email. When's Dave meeting us again?"). She remembers that she's meeting Carol for lunch, so she adds an entry under 'Appointments' as well: "lunch with Carol", where underneath it she writes "1pm", "the Coffeehouse downstairs". When she's done, she closes the note and goes about her business. Later on when it's almost time, a popup (by Evolution) appears on her desktop to remind her about the lunch.

Let's play well together

Bob uses Tomboy for generic note-taking, and also uses Evolution at work to access his mail and calendar, which he uses to schedule tasks and appointments. However, he keeps it closed at most times because he likes his desktop clean with less programs open. While typing ideas for his proposal on Tomboy he first lists down any requirements down as tasks right at the bottom of the page so he can simply tick off items when he's done to check for correctness ("include sales_graph.png", "send copy to Dave"). Halfway through writing, Alice calls to tell him the meeting with Dave has been postponed to 3pm. He doesn't want to switch applications to break his flow, so he clicks on Tomboy and selects the Note of the Day. The meeting, previously added in Evolution, is already in there underneath 'Appointments', listing the time as 12.30am with the alarm set to 30 minutes. So to update it, he simply deletes the time, fills it back with "3pm", closes the note and continues with his writing. At 2.30pm, Evolution pops up to remind him about it.

On the go

Gary uses a touchscreen-capable portable device (e.g. Maemo on a Nokia N800). He plugs in his device to sync with his desktop overnight. In the morning when he takes the bus to work, he wants to see a quick overview of things to do today (it's crowded and it's hard to read on a moving vehicle, so he doesn't want to spend too much time with GUI elements), so he takes out his device, touches the Tomboy icon with his finger, selects the Note of the Day, and sees all his tasks and appointments on the note, scrolling up and down with his thumb. After work when he's buying groceries, he remembers he has a shopping list written under 'Tasks' so he opens up that note again. He drags down the rows of text with his finger and sees his grocery list item written: "Food" under 'Tasks', with the description "Bread (Pat wants wholemeal! Get the BAKERS brand), milk, sugar..." underneath it, so he goes and looks for them in the next aisle. When he's done, he touches the box next to it with his finger to mark it off as completed, and puts the device back into his pocket.


So what's this all about, really? To summarize:

Note of the Day

This is a popular feature where users can jot down their tasks and appointments. It would be nice if every day schedules could be fetched from existing PIMs on the desktop and displayed on this note to give a very clear overview of to-dos.

True Tasks and Appointments

Comparing to any basic PIM, the Note of the Day feature is sadly lacking in semantics. Is the line of text entered there a task? If so, is it completed? Is it important? Tomboy doesn't know, it's up to the user's creativity to 'encode' these information into their task lists. A more friendly GUI is proposed here.

[x] Call Bob Forward client email. When's Dave meeting us again?

This is how a proposed Tomboy task looks like. The checkbox indicates completedness, and a description included afterwards if the user wants to include more information (which is natural. A shorter title is easier on the eyes while skimming). Tasks marked important may be displayed as bold or in a different color, and may be automatically placed at the top while creating a Note of the Day.

[ ] Programming Lecture from 2 to 4pm at Lecture hall 109 Ian will be covering Python. Remember to bring textbook and last week's code printouts! (Sharon wants to borrow.)

This is a Tomboy appointment. The time and venue is displayed as a natural sentence to make it simplistic and unobtrusive, and we have a description of the task displayed after that.

Evolution integration

Or more technically, having Tomboy use EDS as a 'data source' (more on this below). An Evolution task has at least a title, priority, description and status (done or not). This will map almost 1 to 1 to Tomboy's task structure, with the rest being done by guesswork or abstracted from the user. Any changes made in Evolution is reflected in Tomboy, and any important text fields (e.g. time of an appointment) edited in Tomboy should ideally update Evolution as well. In cases where EDS may not be available, tasks will not be managed (no synchronization with a data source nor automation), but appear as normal GUI widgets that users can still freely use to represent their tasks. See also Technical Discussion on Unmanaged Tasks.

Tomboy vs. Evolution

Evolution has a Calendar view where all notes, tasks and appointments can be seen on the same screen. However, from what I've observed quite a number of people don't like, or at least do not prefer, Evolution's GUI. Furthermore, from the perspective of ultra mobile desktop environments (like our Maemo example) Evolution is too heavy-weight an application to be used, and users tend to gravitate towards lighter apps like OpenedHand's Tasks and Contacts. This proposal fills the niche in between: integration of tasks, notes and appointments on an already simple application. No, this proposal isn't intending to completely replace Evolution with Tomboy, because Tomboy is, after all, a note taking application (See Technical Discussion). Remember, the main aim of this proposal is to further facilitate the process of managing tasks and appointments in Tomboy, using Evolution as a supporting backend.

And as a sidenote to the supporting framework:

Data Sources

Generally speaking, are modules built on a data access framework that can fetch data from somewhere, perform something, and present it as rich formatted text for Tomboy. In this proposal, an adaptable software layer is inserted between Tomboy and Evolution in order to achieve Tomboy-Evolution integration. To elaborate, Tomboy .note files are just a "disk" data source, which does nothing more than read and write files. An "evolution-data-server" source would be more complex as we now have two-way synchronization. But why stop at that? A data access framework for Tomboy means we can build "Google notebook" data sources to store networked notes, "diary" data sources for desktop blogging that publishes to an online journal, "basecamp" for project management deadlines... Quite a lot of possibilities.

To conclude this section,


  • By adding basic PIM features, Tomboy users can efficiently manage their tasks and appointments simply using lightweight text editing. Users who will immediately benefit most are those who already use Tomboy for any form of planning.
  • The Tomboy data source framework will provide a modular interface to loading and storing data in Tomboy that can be easily adaptable to fit users' needs. If time allows, the deliverables of this project can be further extended to include modules for some popular PIM services.

Technical Discussion

Things that need to be taken into consideration for the implementation of this project:

Scope and Design

As written previously, Tomboy is a note taking application. This means that any features, no matter how cool it may be, should not overshadow its original theme and design. Thus this proposal should only cover basic PIM features that will cover the needs of most users. Advanced features can be added using plugins once a framework is in place. The UI for Tomboy tasks should be minimalistic (e.g. does not provide all data fields for a Evolution task, but just the basic ones so it doesn't clutter the Tomboy text area). Evolution memos will not be included within the scope of this project, but ideally can be implemented after the SoC. (To be added to Where to go from here). Some other key points:

  • A user that has a lot of tasks might be overwhelmed when they are displayed on the Note of the Day. We'll try to apply certain rules so that only essential items will be displayed. (Extra care so the user doesn't miss an important appointment!!)
  • When creating the Note of the Day, only tasks that are undated or apply to that day (appointments) will be displayed, and will be sorted by importance. Users are free to reorder them by copying and pasting (See below).
  • For other notes, tasks are displayed indefinitely, until they are deleted (Note that tasks in here can only have been created from Tomboy). Once they are completed (ticked) Tomboy updates the 'due date' field to today so this task will no longer be shown on the Note of the Day tomorrow.
  • Note that it is not possible to change the date in Tomboy tasks and appointment (True Tasks and Appointments). In cases where a user really has to manually adjust this, it will be better to delegate the responsibility to a full PIM application. Afterwards, it is up to Tomboy to reflect this changes (See Synchronization).
  • Copying tasks and appointments in between notes and anywhere else is not allowed, yet (I'm not familiar with how it works in Gnome. May update this later if time allows).

Current Work

There is a lot of work for Tomboy going on in parallel. A lot of the ideas in this proposal rubs shoulders against concepts that will probably soon be realized or projects already underway (e.g. version control, Conduit, Tomboy notes server, Google Notebook, previous proposals of Tomboy tasks). Will be investigating all existing work and taking care so we don't reinvent the wheel; code should be reused where possible, API tested and documented, and also collaborate with other projects so we get the best of both worlds.


How will syncing work? Because of the 'persistent' properties of Tomboy and Evolution (both can be opened and edited at the same time) it will be hard to determine which user changes should be accepted and in which case should unsaved changes be discarded, even though it may be undesired. As such, the behavior of Tomboy should be as unobtrusively restrictive as possible. Ideally, this feature should be well documented enough so that users will not be confused as to how syncing actually works. Below are some key points:

  • Ideally, users should never be editing the same Tomboy tasks and Evolution tasks at the same time, but Tomboy should be able to handle this when it does happen.
  • Task updates should be done as soon as the note is closed, or better, when the user is done editing (Revision control would have been helpful to give more fine grain control, but that will have to wait until after SoC). So,
    • New and modified tasks and appointments appear / are reflected in Evolution immediately.
    • Deleted tasks and appointments depend on what the user is doing at present and how Evolution reacts (By default Evolution asks whether to accept or discard the changes).
  • Updates from EDS should be applied automatically when the note is closed. If a note containing the task is open, update it if the note isn't actively selected, or if the task has not been changed.
    • If the user is editing the note at the same time, visually prompt the user that we will have to update the note, what will be updated (show differences) and, regretfully, have to ask the user whether to accept or discard this update. Loss of data in either Tomboy or Evolution is almost unavoidable in this case for now.
    • It is also possible to have Tomboy less-paranoid and simply accept anything the user does (in our example, the EDS version is first accepted, and then the Tomboy version. The former will simply be overwritten without asking. This appears to be the default behavior in Evolution applications); if this is the case, it should be configurable by a preferences key.
  • If an item has to be removed from a note (date changed or item deleted) and the note is open, it depends on the source:
    • Private calendar: Same as previous point.
    • Public calendar: Ask. It's likely the user has no control over the calendar and would like to know what happened before it gets overwritten (See below). No one likes to miss an important date!
  • EDS may be configured to serve uneditable appointments (e.g. Web Calendars). Having an uneditable item in Tomboy may be confusing, so if a user makes changes to it perhaps the item should be duplicated into the user's own calendar?

Unmanaged Tasks

Some Tomboy users won't have access to EDS, e.g. Windows, KDE. Here Tomboy should create their tasks and appointments 'unmanaged', that is, the items only appear as simple UI widgets without any synchronization features, yet still able to aid users with managing their tasks items easily.

User Input

Keeping data integrity is important. We should be able to recognize the difference between "from 8am to 2pm today", "from 08:00 to 14:00" and "dFGeS2$!!". To reduce coding complexity we can just choose a few particular time formats, and subtly display an error if Tomboy cannot recognize it (Tomboy's spellchecker is a good example).


  • A modular data access framework API for Tomboy
  • An Evolution data source for use by Tomboy
  • 'Tasks' and 'appointments' types in Tomboy that integrate well with Evolution
  • Improved 'Note of the day' that displays current tasks and calendar items from Evolution
  • Optional: Additional data sources for common PIM services, such as Google Notebook, Basecamp.

Where to go from here?

This section will be expanded if the deliverables for this proposal have been accepted / confirmed.


Starting from May 28:

Time Task
Month before Background research, understanding Tomboy
Week 1-3 Will be completely swamped by exams and thesis work, but will be actively producing screenshot mockups and gathering feedback
Week 4-7 Start on June 24th. Data access framework and Evolution data source completed by July 1st
Week 8-9 Start on July 9th. Tasks and Appointments.
Milestone 1 - Public accessibility test
Week 10 Start on July 23rd. Data Synchronization
Week 11-14 Start on July 30th. Code cleanup, testing, leeway time for adding features
Milestone 2 - Public acceptance test


  • Draft 1: Initial version.
  • Draft 2: Changes to the Timeline, added Case Study section, minor text edits.
  • Draft 3: Stance of this proposal is no longer as an Evolution replacement, included two public tests in Timeline as milestones, added Technical Discussion. Bunch of other minor text edits.

About Me

I am a 23 year old university student, Malaysian, currently studying for my Honours degree in Information Technology at the University of Queensland, Australia. Since college I have taken an avid interest in free and open source software, even taking up a lead C developer position at an open-source game project for 1 year.

After switching to Linux recently, I've tried and tested a wide range of offered software, and have actively supported friends (many who've only heard of Linux before) and other users on forums and on IRC. From these experiences I've learned a lot about how Linux ticks, what really attracts people to Linux and more importantly, the kind of expectations people put on Linux software. And it is for this precise reason I'd like to take this chance to contribute back to the community by writing some potentially experience-changing code, not just for myself, but for every other open-source user as well.