Hi Stephen. Your nickname "steveire" already gives away something about your origin. Could you introduce yourself so our readers get to know a bit more about you?

Sure. I've been using the handle steveire for a few years now on IRC and other places. For non-Irish people, it looks like a "Steve" and an "Ire" for Ireland, but in fact it's a "Steve" and an Éire, so on the rare occasions that I say it, I pronounce it "steve-air-eh". I moved from Dublin, Ireland to Berlin in summer 2009 to start a job at KDAB.

You recently won a Qt 4.6 contribution award. What were your contributions?

I contributed some new features and API to the Qt Model/View system, most notably, API to move rows and columns in a model. I had seen a gap in the API and wanted to fill it in a way that would make it easier for myself to move items in a model or a proxy without rewriting the same code everytime.

Ah, model-view. That's quite abstract. What features does your contribution add? What did you make easier?

The main feature of the contribution is convenience. It was already possible to move items in a model by emitting the layoutAboutToBeChanged and layoutChanged signals and updating QPersistentModelIndexes in the model. However, it is not trivial to get that code correct. There are subtleties to deal with when moving items to a different branch in the tree, and a different set of subtleties when moving within the same branch (Are you moving this item up or down?). There is also the need to make sure a move is valid. For example, a QModelIndex can not be moved to be its own descendant.

The new API takes the responsibility away from the developer of dealing with all these difficult tasks. My contribution was to implement all moves in a generic way so that the implementer of a QAbstractItemModel must only do something like this:

if (!beginMoveRows(sourceParent, start, end, destParent, destRow))
    return; // Early return if this is an invalid move.
// Move the internal data in the model
endMoveRows();

Of course, I didn't get this right first time. A secondary part of the contribution was a complete set of unit tests for the move API. This has already proved to be very valuable, because I found and fixed a significant bug in the code just a week before the release of Qt 4.6.

How does this work on QAbstractItemModel relate to your work at KDAB?

My job at KDAB currently mostly involves working on the Akonadi framework, a scalable, fast and generic framework for access to PIM data. Part of the goals of Akonadi are to make it easier for anyone to write an application to access and manipulate PIM data. I wrote a generic model, the EntityTreeModel (which is-a QAbstractItemModel), and several proxy models to make it easier to "click together" some pieces to create a PIM application with that model and some views.
This means it is easier to write a new addressbook application, a new calendar application, or significantly for KDAB, a new Kolab Client.

I heard rumours about virtual email folders in Akonadi. What role does QAbstractItemModel play there?

Akonadi often deals with data in hierarchies - A folder tree on a filesystem, a nested set of maildirs, or a tree of collections and items on a groupware server. Such structures allow users to sort and categorize their data, but they do not make that task any easier.

Virtual folders are a concept in Akonadi which allow you to organize items into custom structures from multiple different locations. Typically the contents of a virtual folder in Akonadi is the result of a search query, or a collection of items with a similar annotation like a semantic tag. Because the virtual folders operate independently from the actual location of the data, similar items from multiple different locations can be grouped together. Even different types of data can be grouped together if that makes sense. For example, if you have some emails and some contacts tagged as relevant to "development work on Kolab", they could be grouped together for the purpose of a special ui element such as a summary or overview.
QAbstractItemModel plays a role of information hiding in this concept. Internally, the EntityTreeModel recognizes that a particular collection is virtual, and therefore contains only links to items, but externally there is no difference to the application, which simply always deals with QModelIndexes. There is also no difference for the user except that a virtual collection may have a special appearance for being a search collection or a collection of tagged items.
The advantage of having that abstraction is that there is no special cased code required to operate on virtual collections through the model. That means that proxy models can trivially be used where appropriate and can reasonably be expected to work in all cases.

You won an N900, Nokia's new Maemo-based smartphone. What are you planning to do with the device? Any Maemo development you'd like to get into?

I haven't yet looked in depth at Maemo, but knowing that it will be using more Qt in its next iteration should lower the barriers for me to start using it. I will initially be using the N900 as my new phone, but will also be working on porting Akonadi and the rest of KDE PIM to work on the device.

You're also working on notes in KDE PIM. Any news about this? With KDE moving to Akonadi, will notes make use of this as well? What's the advantage?

Notes are a part of PIM and will also be accessible with read/write access through Akonadi. There are several advantages to this, mostly generic advantages that come with all use of Akonadi. Firstly, it allows networked storage, or otherwise storage which is not always-connected. Akonadi caches all changes made while disconnected, and replays them when the remote resource is available again. That means that you can store your notes on a groupware or ftp server, and edit them from multiple locations and have it all synchronized. Applications which consume the notes will not even be aware that the remote is not locally stored (but locally cached only) because all Akonadi applications use the uniform EntityTreeModel interface parametrized by type.
Of course, notes will be synchronized locally too. If you have a note in two visible locations, say kjots and a desktop note, and you edit it in one of the locations, it will instantly appear to be updated in the other location. This is an almost obvious result of the use of the Qt Model View framework and the model/view architecture of Akonadi. Different applications do not have to communicate with each other to keep up-to-date. They simply display what is reported by the model.

Thanks for your time, Stephen, and good luck with your plans for QAbstractItemModel, Akonadi and KJots!