Month: May 2006

I’ll explain it using the new API for getting headers in tinymail. You can see this code in a working demo (that adds a GtkTreeModelSort) at this location.

You don’t see an ‘iterator‘ here: the TnyListIface is the iteratable type that doesn’t depend on Gtk+. The iterator itself is of course being used in the implementation. It can also be used by the developer who’ll be using the tinymail framework.

Update (fwd reply from Dirk@maemo): Updated “modest” to the new API — works fine here so far.

static void
refresh_current_folder (TnyMsgFolderIface *folder,
	gboolean cancelled, gpointer ud)
{
   GtkTreeView *header_view = ud;
   if (!cancelled) {
      #define TLI TNY_LIST_IFACE
      TnyListIface *model = TLI (tny_msg_headers_list_model_new ());
      tny_msg_folder_iface_get_headers (folder, model, FALSE);
      gtk_tree_view_set_model (header_view, GTK_TREE_MODEL (model));
   }
}
static void
on_folder_view_tree_sel_chgd (GtkTreeSelection *sel, gpointer ud)
{
  GtkTreeModel *model; GtkTreeIter iter;
  if (gtk_tree_selection_get_selected (sel, &model, &iter)) {
     TnyMsgFolderIface *folder;
     gtk_tree_model_get (model, &iter,
       TNY_ACCOUNT_TREE_MODEL_INSTANCE_COLUMN,
       &folder, -1);
     if (USE_ASYNC) {
        tny_msg_folder_iface_refresh_async (folder,
          refresh_current_folder, status_update, ud);
     } else {
        tny_msg_folder_iface_refresh (folder);
        refresh_current_folder (folder, FALSE, ud);
    }
  }
}

Tinymail now integrates with GnomePasswordDialog and GNOME keyring. This means that it stores your passwords using the GNOME keyring service. (update, Evolution these days can also support gnome-keyring)/

The tinymail framework will only use this implementation if you use the gnome features in combination with the libtinymail-gnome-desktop platform library implementation. Other platform implementations of course need to implement getting and forgetting the password themselves. They can of course reuse or look at the code of the implementation for the GNOME desktop.

Note: Somebody please write the GNOME keyring API documentation. It’s almost undoable to understand what you need to do if you want to use the GNOME keyring service. It was even harder than using Camel. Oh and, while you’re at it, update the developers.gnome.org website so that the GnomePasswordDialog API reference documentation is also available online.

RE: Java, and Survival of the Most Adaptable

While Miguel mentions the quote about railways and rail lines, and while I agree with the bottom line that standards are very important, I’d like to highlight the very first line and the title of the blog entry of Jonathan Schwartz:

Change is a constant at Sun. So long as the market’s changing – or so long as we can change the market – we’re going to evolve. As Darwin said, it’s not the strongest organisms that win, it’s the most adaptable.

I’ve been working the entire afternoon on documenting the tinymail framework. You can find it online and in the source tree of tinymail.

Now that I’m done with it, I can say things like: “Don’t talk about documentation. Do it!”. And other bitching like that. Moehaha. (poor guys that don’t document their crap).

Anyway, I hope people will enjoy the added documentation. Don’t forget there’s also some UML class diagrams for tinymail (look look, the anti buzzword people suddenly get angry now!). And I’m planning to keep those even more updated than the API reference documentation. In my opinion, there’s nothing as important as developer documentation for a framework or library.

Tinymail

Today I did mainly build environment related things. Like making sure tinymail is translatable using gettext and getting the gtk-doc API reference documentation generated. I had to do some nasty stuff to get that working. But eventually I got it working. I’ve put a version online. That version is, of course, already outdated. Because any online version is going to be outdated the first millisecond after somebody uploaded it.

Garage & modest

It looks like the Nokia/Maemo folks have put Garage online. On Garage you can find for example modest, their E-mail client that is being build on top of the tinymail framework. It looks like you can also check out the source code.

Two new screenshots demonstrate the possibility to use NNTP with Tinymail.

These two new screenshots demonstrate the possibility to use NNTP with tinymail. Note that this is highly experimental. Well, all of tinymail is of course experimental.

Last night I wrote about a little tool for real-time monitoring of the memory consumption of a piece of software.

You can find it here. If you untar that you’ll find a valgrind_massif_ms_main.diff which you’ll have to apply to valgrinds massif tool release 3.1.1 (it’s the latest version on their website). I didn’t cleanup the crap code. So the code is as ugly as can be.

Oh by the way. Using it to monitor evolutions memory consumption gives funny results.

I wanted to see how tinymail consumes memory in real time.

By that I mean, let my system give me (the developer) a graphical idea of how much memory the software is using if I perform a specific action. And to check whether or not I’m getting the memory back when I’m done with the action. However. Not after a full session by viewing a .ps file. This is what a standard valgrind/massif makes possible.

No, I wanted to ‘see’ the curve grow ‘while’ running my software.

For example when I open a folder, I expect memory usage to grow. If I now click on an empty folder, I expect the memory usage to drop (because the first folder is now being uncached).

So I hacked massif a little bit and wrote a little Gtk+ tool that reads the information from massif and plots it to a drawingarea. It’s not really in a usable state but I created a screencast to give you guys the basic idea. It’s a 3.3 MB GIF animation which will eat your memory if you use Firefox for viewing it. But it’ll work.

I don’t know when nor if I’ll ever get this funny thingy in a usable state. Note that you also need a few small changes to the massif ‘ms_main.c‘ file. And the tool is a quick-put-together glade-2 generated piece of crap code at this moment. Oh bleh, I’ll probably make it usable. It’s just a little bit late now. And I have to go to work/my customer tomorrow. I hack to much late at night :-). So I already told myself I’m not going to finish it tonight. Don’t ask!

Dirk-Jan of the Maemo team in Helsinki posted a new update on the status of “modest”, their attempt to create an E-mail client for small devices.

I’ll again translate the tinymail-related stuff from Dutch to English:

This week there was a lot management tasks to do. Therefore I had less time for modest, our experimental E-mail application. We did, however, had some progress. Following Philip is/has become interesting — we use his tinymail project –, the high frequency of changes demands constant refactoring at our side. Not a big problem — This is more or less how the/our daily progress goes:

HERE, you see, it takes all the running YOU can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that! — de “Red Queen” in “Through the Looking Glass, and What Alice Found There”, Lewis Carrol, 1872.

But as said, this is good. We try to run as fast as possible, and we are getting somewhere. The screenshot shows a little bit of what we’ve done. This screenshot is, by the way, our throwaway prototype, which we use to build the rest of the application. The “real” GTK+-version will follow the HIG — so have no fear :-) –. Professionally is the Maemo-version of course even more interesting, but I definitely also want a good GTK+-version.

The screenshot isn’t using the MozEmbed-stuff Philip in his screenshot uses. Therefore is viewing spam also less interesting :-). Luckily is tinymail very flexible. For example if I want to start using GtkHTML, it’s very easy to add/replace that. I can simply create a TnyGtkHTMLStream class which implements the TnyStreamIface-interface. And done! Let’s do that!

Other than that I’ve been adding some UML class diagrams that illustrate the design of tinymail. Soon will the gtk-doc API documentation also be finished.

Yesterday I got complaints about class diagrams not having enough bling. And that MacSlow has cooler blogs than I have :-)! People want anti aliased bling screenshots. Right? Yes? Is that true? Well … spam has a lot bling, no?

Therefore I just implemented the primary feature of all E-mail clients in tinymail: Viewing spam.

I’m using Gecko/GtkMozEmbed at this moment. I’m going to have to beautify the code a little bit before I commit it. There’s also some issues with finalizing the GtkMozEmbed instance. It makes everything hang in some recursive loop. Grmbl.

Update: It’s hanging in PR_WaitCondVar, does somebody know how to fix that?! It happens after the exit(0), so it’s probably some C++ destructor of the firefox/gecko widget? Does it happen on your platform? I’m testing on Dapper. Let me know if you test tinymail.

Update: The implementation is committed in subversion. Have fun.

A problem, however, is that now tinymail can view spam, you guys probably want me to also implement deleting messages, right? Crap.

There’s (might be) some people who are interested in tinymail development. I just posted a plan-of-action. Please read if you are planning to (someday) join the software development iterations of tinymail. Note that this doesn’t mean that tomorrow a huge team of developers will be working on tinymail. But it’s my idea of how to be as Agile as possible during the tinymail development lifecycle.

I’m as unwise as Socrates (probably) thought he was. By that I mean that I might be wise only in so far as I know that I know nothing. Therefore I’m very interested in suggestions.

If you request an E-mail, Evolution will block the worker thread for getting your E-mail until the last folder you clicked is loaded. Try it — I’m not very sure what evolution will and what it wont do. Tinymail, however, will now, if you click an e-mail while you are loading a folder, restore the original folder and show the E-mail immediately. After it canceled the folder-loading request. It assumes the user wants to stay in the current folder if she’s going to read a message in that folder.

It has the same behaviour for switching a folder. So when you are loading a folder and you click a new folder, the request for loading the folder is canceled and the new request will happen instead. These two camel cancellations make tinymail very responsiveness.

I also removed the need for gdk_threads_enter in the status notification handler by throwing it to the GMainLoop. So the tinymail application developer does not have to care about threading issues in gdk/gtk+. The tinymail library takes care of that.

Update: About behdads announcement: I just added some tinymail proposals to the SoC ideas wiki page and applied for SoC mentor. I don’t know if it’s a good idea but if students are interested, feel free to propose it. Also note that I haven’t yet been accepted as mentor. Update-update: behdad accepted me as a SoC mentor.

In this blog entry — which I’ll now translate –, Dirk basically tells us he hasn’t got to coding yet this week. Others, however, did. He says it’s nice that there’s progression being made on tinymail. He says that they are using tinymail for an experimental open-source e-mail application for the Maemo-platform (and for “normal” GTK+). Called “modest”.

Jesse is also asking for a snapshot release which the Fedora team might soon package in Fedora extras.

I know I often say I try to avoid threads in tinymail. This one is inevitable: Tinymail is going to support two methods for getting the headers.

The first method has been around for a while now: normal synchronous getting all the headers in a folder. This will return you a bunch of small proxy instances that can be used in for example the custom tree model. You have the option to synchronize or not to synchronize with the service. Synchronizing of course takes a noticeable amount of time. And unless you do something about it, your user interface will block during that time.

The second method is new. The second method or the asynchronous method will launch a small thread that will, in the background, synchronize your folder instance with the server. It will callback on the GMainLoop and it will tell you about the status (status notification is in-thread, the callback-on-finished is thrown to the GMainLoop). You are supposed to reassign the model of your treeview when the on-finished callback invokes. During that reassignment you’ll ask for a new list of proxy instances using the normal synchronous method. This time you (of course) no longer have to choose the synchronization option. So it will be fast.

I also made sure camel cancellation is integrated. What is that? Well, say the user clicks per accident on a folder. He notices it’s the wrong folder and rapidly selects a new folder. Does the user want to wait for the previous folder to be loaded? Probably not! Tinymail will automatically (when using the asynchronous method) cancel the request and will fulfill the new request instead.

The result is a very snappy tinymail with a non-blocked ui. Even if you never synchronized a specific folder with the service, the ui will not block. I didn’t yet implement a progressbar for the demo-ui. But using the asynchronous method this is very easy to implement. For status notifications, you’ll have to do the gdk thread locking because at this moment is the status notification in-thread and not thrown to the GMainLoop like what I did for the on-finished callback. I’m not sure if it would be a good idea to throw it to the GMainLoop. Maybe I will.

So.. I might refactor things a little bit. And as usual is this stuff experimental. No API promises.

You can of course svn co https://svn.cronos.be/svn/tinymail/ and try this new stuff out yourself. The default compilation flags are set in such a way that libtinymail is low on memory usage (a little bit slower) while the demo-ui will use the asynchronous method for getting its header information.

A libtinymail developer will not have to worry about all this. He’ll just have to code a few simple lines: take a look at the ASYNC_HEADERS ifdef. The ifdefs also show how small the difference between using simple synchronous and asynchronous can be.

Look, the peak is gone and I’ve cut another two megabytes of ram memory from tinymail. I also improved the load speed (a lot) and the click-speed (snappy feeling). Now Tinymail even works fast when running it under the massif valgrind tool.

Please check it out and try to find problems and issues. Maybe even help me a little bit. I’ve recently posted a todo list (some of the items are already solved) to the mailing list. I’m also looking at implementing a libtinymail-spruce. Nevertheless, this measurement proves that camel can do it. But I still think camel could use some API improvements like simplifying things. Which is why I’m looking at libspruce.