Maemo related news (english)
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
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.
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.
It’s been a lot of work. But Modest first beta is finally here. For Chinook/OS2008 users, it’s easily available:
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 reports should go to Maemo Bugzilla. Section Communications/Modest. We’re willing to know your problems, and/or enhancement requests.
See you in bugzilla!
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:
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).
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:
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.
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.
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.
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:
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.
Today I’ve read about the great work of Iago Toral (a workmate at Igalia Innovation) with Gnome Buildbot. He’s been doing some efforts to integrate unit tests of Gtk+ in the build loop.
Using check, he’s generated wonderful HTML reports, and a nice integration with the standard buildbot compilation view:
You can read more information about Iago’s work in his blog entry “Gnome buildbot and integration of unit tests”. Hopefully we’ll get a public deployment of Gnome Buildbot soon.