José Dapena blog

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).

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.