Month: April 2008

Summer of code 2008

I’m going to mentor three Summer of Code applications.

• E-mail activity for OLPC by Shikhar Bhushan
• Seahorse integration in Evolution by Zhang Shunchang
• SuperRandom, a predictive listening plugin for Rhythmbox by Charlotte Curtis

One of the Igalians who developed Modest and among many of his Tinymail contributions implemented the libcst implementation for handling certificates in Tinymail, José Dapena Paz, is going to mentor Zhang Shunchang’s application together with me.

Picking up what I left in 2005

I also just picked up AsyncWorker. I made it a little page and with the help of Tinne I improved its API documentation. Perhaps I will do a release someday (I never did, actually). Thing is that I hate the work involved with releasing. Especially since most of our development tools stink.

Note that my super fantastic lovely girlfriend, Tinne, has her own blog now. It contains a bunch of photos of our stay in Durham UK. In a few minutes, she just told me, she will put online a funny photo of me holding a fish bowl filled with cocktail.

While I was gathering some info about a DBus related task that I’m doing at this moment, I wrote down whatever I found about DBus’s glib bindings in tutorial format.

A few other people have done similar things in their blogs. This one explains how to use org.freedesktop.DBus.GLib.Async a little bit too.

If you find any mistakes in the document, it’s a wiki page so please just correct them.

I just released Tinymail’s pre 0.0.9, enjoy!

I noticed that more and more people from several specific cities are visiting Tinymail pages, and I know at least a few companies and organisations who are using Tinymail right now.

My personal opinion on development frameworks is that if they come without documentation, they are worth as much as vaporware.That’s why I started first, at an early stage, with writing the API documentation of Tinymail and then Tinymail’s trac, which holds a collection of examples and on top of the API documentation also explains most of its types and how to use them.

This was not sufficient. I wanted to write a test E-mail client to find the source of bugs in Modest. While I was doing that I decided that this test E-mail client was going to be documentation too. Documentation in the form of source code that itself required documentation.

I started TMut’s trac to deposit that documentation. Yesterday I mentioned that I implemented simple account management in TMut, today this is ~ finished. Here is the documentation about that source code.

New items:

• TMut’s account store
• Account manager
• Account editing

Former items:

• Creating messages
• Select a folder window
• TMut’s menu, its first screen
• Showing the summary of a folder
• The message view component

You guys remember TMut? It’s an E-mail client for small screens that uses Tinymail. It serves as an actual E-mail client, as some code that you can use to peek at while developing your E-mail client and as a piece of code where you can derive your stuff from (although TMut’s current build is not set up to build TMut’s classes into a library, you could easily do this and then subclass TMut’s high level components).

What makes TMut unusable for non-software developers is that it has no account management. You need to do that in for example GConf (depending on what implementation of TnyAccountStore your TMut uses).

At Modest we need to test Tinymail’s account management capabilities without executing all of the extra code involved in what Modest does whenever you manage its accounts. Therefore I started putting in place some code to have basic account management in TMut.

It’s, as usual with the things that I blog about, unfinished.

Iterators

Now that Murray has posted about the iterators idea I can no longer hide.

Together with Jürg, the Vala man and Murray, who before becoming a pregnant guy was and still is coding on things like Glom and gtkmm, I’ve been writing up a document. This document explains iterators like the ones you’ll find in .NET and Java.

This is related to the Iterators concept because the document about iterators could be part of a solution for this.

I once had to write a custom GtkTreeModel (I think I still suffer from vertigo) and therefore I sent treeview Kris an analysis about this.

There’s a rule that an interface should be a contract for solving exactly one problem.

Use interfaces to say “What objects can do” or “What can be done to an object”. You can let a class implement multiple interfaces. There’s absolutely no need to make huge interfaces. An interface should define that your class “Does One Thing”. Another interface defines that your class “Does Another Thing, too”, and a last interface defines that your class “Also Does This”. My class Z can do D, E and F. Therefore: class Z implements D, E and F.

Instead, the contract being GtkTreeModel requires you to solve five problems:

• being iterable: you can go to the next node
• being a container: you can add and remove things from it
• being observable: it notifies a component about its changes
• being a tree: sometimes items can parent other items
• having columns: it’s something that describes columns

Summarizing: interface TreeModel means BEING a D, E, F, G and H at the same time. Correct would be if you specified that TreeView requires a model that does D, does E and perhaps also does F. In case treeview is showing the things as a tree, it requires that the model also does E and does H.

GtkTreeModel should have been five different interfaces.

Shocking! But in my opinion, true.

The consequence is that having to implement a GtkTreeModel has become a difficult task.

“You have to implement solutions for all five problems anyway!”, you might think. That’s true. However! If there were five interfaces, other people would have made default solutions for four other interfaces. Meanwhile “you” focus on “your” specialization. For example Rhythmbox and Banshee are specialized in huge models that contain a specific set of data that must be searchable. Preferably search and sort are done by a database instead of a model-filter.

Banshee and Rhythmbox developers:

• … don’t have to care about the Columns problem
• … don’t have to care at all about the Tree problem
• … don’t have to care about the Container problem: they never need to add nor remove things from it because they set up their model instantly by passing a query to a data source. Maybe the feature “remove from playlist” requires solving the Container problem?
• … unless they support inotify on the MP3 folder of the disk, they don’t even have to care about the observer problem

Yet with GtkTreeModel you have put the burden on application developers to solve all five the problems in their model. No wonder Banshee developers decide to code their own TreeView in .NET!