What’s going on in Modest: new Gnome/Moblin port.

As many of you know, Modest is the mail client of Nokia n810 and n900 devices. As that, there is a huge effort on it, to make a really good mail experience in those devices. But for last years, the effort was completely concentrated on Maemo platform.

Last months, Sergio Villar and me have been working on bringing the Modest user experience to both Gnome and Moblin, using our community projects time here at Igalia. The work was based on a very interesting effort from Javier Jardon this summer.

The main goal was trying to make the behavior of Modest in Gnome as similar as possible to the counterpart in Fremantle/Maemo5. It’s still unstable, a work in progress, but it’s already showing how it will look like:

List of folders in Modest Gnome

You’ll see a really big difference with other mail clients available in desktop. It’s really oriented to keep things really simple and straightforward, so Modest is not only light, but its user experience is kept light too following a similar style to the one used in Fremantle Modest.

Most use cases are already functional. We’ll try to do a new release next week, and, if possible, also offer some packages for easy testing. Stay tuned.

Modest talk at Gran Canaria Desktop Summit. Slides and screencast

On monday we (Sergio and me) had the talk about Modest for Fremantle in Gran Canaria Desktop Summit. Good to see some people interested in our work.

Just Modest is getting a really pretty good shape. Definitely, it’s really cool what we could do with Hildon 2.2/Gtk toolkit. We moved to a really great UI in a few weeks! Also, lots of bugfixes, so Modest is far more reliable now, and also more easy to use than ever.

The slides: Modest talk at Guadec/Desktop Summit 2009

And the  screencast of Modest in Maemo5/Fremantle SDK

New Modest plugin system. Anyone willing to implement RSS support?

As Quim announced yesterday, the Beta release of Maemo5 SDK has been released.

It includes our beloved Modest, which goes back to the opensource development. It’s been migrated to GIT, and you can see and track the development of the project from now on, but also browse the history of the project. See more about all of this in Modest Garage project webpage.

One very interesting new feature you’ll get with Modest is the new plugin system. The protocols code has been refactored, to allow extending Modest to support new protocols, in addition to the ones supported in standard Modest (IMAP, SMTP and POP3). And this has been exposed through a plugin API.

What you can do with this is adding plugins adding support in Modest for RSS, NNTP, etc. Just imagine the kind of mail server you would like to see in Modest!

We’ve added to the new created Modest development wiki some information about Modest Plugin development.

One final note. This plugin API is still not assuming an API/ABI stability, but this is our goal. Bad thing is you’ll need to keep your development in sync with Modest (at least for now). Good thing is that you can still contribute or request changes to the plugin API, and this won’t be a hell.

Gtk 3.0 and beyond. Team requirements

The 3.0 approach of “no new functionality”, only wiping out weird stuff is good. But I have some concerns on the timing for the plan. If 3.0 is simply wiping old stuff out then, why should we wait to next Spring to finish this? Or, once we have it stabilised, why 1 more year of development to get new features? The total gap of 2 years is reeeeeeally long. Can we go faster?
I see the community has the will to make Gtk better, soon, but the problem seems to be that the community doesn’t have resources for this. So, in parallel with the implementation plan for Gtk 3.0, we may think about a organization plans for 3.x or for 2010. Do we want to make Gtk grow faster, better? Is current Gtk+ core team big enough for what we need?

Currently the list of core developers in Gtk+ as you can seen in the web page has 10 members. A goal would be something like this: let’s have 20 developers that deserve been in that list in 2010.

But getting people trained and productive so they deserve getting a core responsibility is hard and slow. Do we want Gtk+ grow healthier, faster, safer, with more quality? Don’t we feel that the current  core team members are heroes that can miraclously maintain and grow Gtk+ because they are really good doing their work? Can we help them? Any effort on growing the core team will take a while, so we should take this seriosly soon if we want results in a reasonable schedule.

Modest! Time for feedback

It’s been a lot of work. But Modest first beta is finally here. For Chinook/OS2008 users, it’s easily available:

Direct install icon

You can read more details on the release in the blogs of other Modest developers: Dirk-Jan, Philip, and my workmates at Igalia Sergio, and Berto.

But I want to highlight here that Modest is Beta. Not in the sense of “huh, don’t blame us if it fails”, but the opposite. Just blame us, cry, shout. We want to make sure Modest is better and better, and we just need you write good bug reports, so that we can work on them.

Bug aggregation

Bug reports should go to Maemo Bugzilla. Section Communications/Modest. We’re willing to know your problems, and/or enhancement requests.

See you in bugzilla!

Some ideas of improvements for file chooser

I’m not saying that file chooser is bad at all for selecting files, but there are two features I would definitely love in it:

  • Being able to get the size of the file.
  • Thumbnailing support

Size of the file

The use case I found where I need this is “adding attachments in evolution”. If I want to send a mail, I usually want to avoid sending very big files as this is not very good for most mail accounts people use.

If I want to do this with Evolution/Gnome, I have to open the folder with Nautilus to check the size of the files.

In fact, you can find other interesting information you’ll want to check when you are opening a file with file chooser. For example, the id3 tags of a mp3/ogg file.

I suppose the UI design experts can point good ideas about this. For me it would be enough if the contextual menu of a file would offer a “Properties” action.

Thumbnailing

We don’t need thumbnailing only for opening a file from gimp or to attach an image. The thumbnail of a image works better than the file name to describe the contents of a file, so we should enable the user to use it to know which file he’s managing, even when the application is not a imaging related one.
So I suppose it should enable thumbnails by default.

And a last very easy to implement idea

Just provide a way to open in nautilus a folder you’re viewing in file chooser. Not sure how, as a “open folder” button would lead to confussion. Maybe “browse here”? This way you could easily access to all the operations available in nautilus for files and folder, without having to browse to a folder two times (one in file chooser and one in nautilus).

Purging attachments with Tinymail (or being smart with small storages)

Scenery
Imagine you have a pretty mobile or portable device with email access. You love using it for reading mail just because you don’t have to use your laptop or pc, and your fantastic device can go in your pocket or handbag.

This device is fantastic, yes, but it has a limited storage capability. And you usually get a lot of mails, and some of them really big (with images, audio files or even videos). It’s not too difficult to exhaust the storage in some days or even hours.

Tinymail purge API

I added an API to Tinymail that lets you remove attachments stored locally (remove from cache in case the message is from a remote folder, or remove permanently if the folder is stored locally). The API
methods are these:

  • tny_mime_part_set_purged (TnyMimePart *part): this method marks a mime part to be purged.
  • tny_msg_rewrite_cache (TnyMsg *msg): this method rewrites the message to local storage (cache or not), but removing the attachments marked as purged.

Then, if you want to remove some attachments from a message, you only have to mark them as purged using the set_purged method, and then, make the change persistent with the rewrite_cache method.

Currently this is only available for IMAP and local MAILDIR provided folders, but it shouldn’t be too difficult to add support for this to other providers.

Implementation

The inners of the purge method are really simple. The only thing set_purge method does is setting the Disposition field of the mime part with the value purged. In camel backend:

camel_mime_part_set_disposition (priv->part, “purged”);

This mark is mostly innocent, and the implementation is the same for any mime part, independently of the provider (IMAP, maildir or whatever).

Then rewrite_cache simply rewrites all the message to the local representation of the message, but ignoring the contents of the mime parts marked as purged this way. What we get this way is a reduction in the local storage (we don’t expunge the header of the mime part, only the contents). We also keep more or less the same structure of the message, as the original mime part headers are still stored, even when they get empty contents.

Conclusion

The Purge API gives you more freedom to choose what you want to keep in your storage. You can not only wipe out full messages, but also wipe out specific attachments you don’t want to keep.

Gnome buildbot released at FOSDEM!

Yes, as expected, Iago Toral published the work in Gnome Buildbot at FOSDEM. You can read his announcement in the blog.

Briefly, if you maintain a project in Gnome, and want automatic tests running, then Gnome Buildbot may interest you. And, if you have a project built using jhbuild, then it’s easy to create a Jhbuild based buildbot as the one for Gnome. Just ask in #build-brigade.

Tomorrow, talk about Build Brigade in FOSDEM

This Saturday, Iago Toral will be presenting Build Brigade at FOSDEM. He’ll be presenting some work that we’ve been doing last months, including the Gnome Buildbot. More information in FOSDEM web and in his blog:

I talked previously about Gnome Buildbot. Briefly, it’s a Continuous Integration based in Buildbot service that uses jhbuild to compile the full Gnome moduleset. It runs tests and returns coverage reports for many modules.

WikiPatterns

Via Agile testing blog I knew about Wikipatterns, a repository of patterns and antipatterns about wiki adoption and usage. Very interesting work.

I would highlight some interesting entries:

  • Overrun by Camels antipattern: avoid using CamelCaseNames, and use real language phrases (for example, name your node as “Node with contents” instead of “NodeWithContents”. This makes the wiki easier to read, and mainly, easier to search in.
  • Poker pattern: put even trivial things in wiki, to show the null barrier to create new content. Trivial things as this: the scores of the frequent, after-hours poker tournaments.
  • Magnet pattern: have some content exclusively in the wiki to force people to use it.

In Igalia we’ve been using wikis+mailing lists for internal communication for a long time. In Gnome we’ve got Live wiki. And many other communities have found wikis a powerful resource for communication and documentation. Good reading for all these groups.