Day: February 7, 2006

I just added a quick class diagram that describes the layout of libtinymail, libtinymail-camel and libtinymailui.

Not yet related, but might become related, is this tryout that I’ve been working on a few hours ago. I created for example a GIterIface which is an interface for an iterator. I implemented, as an example, a completely useless glistiter (and a demo of course). Actually it’s not useless as the iterator pattern abstracts iterating over list-types. So the iterator makes it possible to iterate over multiple types of iterateable list-types. I’m planning to, for example, also create a ghashtableiter. Using the exact same interface you could then iterate both a ghashtable and a glist while it wouldn’t matter for the consuming component what the list-type originally was. This might sound totally useless if you haven’t used the iterator pattern before. Most Java and .NET programmers can probably tell you why this is important. It often makes iterating slower yadiyada, but for a lot beginner-programmers it’s nice as they will be forced to correctly use the list-type (the iterator implementation for a specific list-type is typically implemented by an experienced developer).

There’s a problem with the current comparable type in gtk+: the gtktreeiter. GtkTreeIter is a type by itself, it’s not implemented as an implementation of an interface that can have a different implementation. This makes it more difficult to create gtktreemodel implementations with a specific iterator for a specific list-type. Or it makes it more difficult to reuse that iterator implemenation for other parts of your project.

This could be, in my humble opinion, one of the reasons why it might be complex and/or frightening to implement a custom tree model. Something that a lot developers should do instead of using the standard gtktree -and list store.

Other things I’m trying out: a GBindableIface, a GModelIface and a GListModelIface. All these things need a lot more brain-time. It’s something I’m cooking. I know I’m being stupid by already showing this. I know I will very likely get flamed about this. That’s okay, I’m getting used to that anyway (xdg-list). Danw is right.

Anyway. The idea of this concept is to bind data to components. For example make gtktextbuffer implement gbindableiface and then g_bindable_iface_bind (buffer, datasource). Make it possible to define a gbindablebehaviour and assign it to the gbindableiface. Something like g_bindable_iface_set_bind_behaviour (buffer, gda_datasource_to_string_bindbehaviour_new()) and datasource = gda_datasource_new(). Anyway. For this to work on a gtktreemodel, I need an iterator which I can instruct how to function when calling its next method. With the current gtktreeiter I can’t do that.

You can tryout this demo which implements a datasource that reads from a file on the filesystem. Just a silly example.

Also make sure you checkout this thingy. It makes it possible to synchronize gobject properties.

As you can see, I’m sickening glib and gobject with sick evil interfaces. And I love doing that! I guess I should be burned and severely punished. You can do that, visit FOSDEM.

Tinymail now shows both the folders and the headers for each folder you select. Gaaah, I know you guys don’t believe me if I don’t post a stupid cute screenshot. So here you go:

I immediately picked my largest folder: my spam account INBOX folder. This is already using the custom treemodel, so it loaded extremely fast. But that is normal, as I’m only requesting the visible camel-message-info instances. I haven’t yet fully tweaked it. This is just the very first prove of concept. I will prove that you can, using camel and some very simple design patterns, write an e-mail client that has only the visible items in memory. And that a device like the Nokia 770 can, that way, easily show an extremely large e-mail folder. Once I’m really sure only the visible ones are requested, I’m planning to experiment with compressing the items in the base-directory which camel uses to on-disk-cache headers. Once you have full control over which items are requested, such tricks become useful. As it will need to decompress recently-new-visible header information, scrolling the treeview will of course become a little bit slower (I can also do it in a thread, using something like asyncworker).

If I can reduce the amount of disk-space, a 256 mb flash disk might hold all my spam E-mails headers of the last three years. Or perhaps there’s a better database-engine solution for this? Perhaps I should check out the status of that disksummary branch. I sure have plenty ideas to make camel a good candidate for mobile devices.