In the realm of mailnews, there are a few parts of the code that don’t really get all the attention they deserve. One of them is the compose window.
> jcranmer: libmime and compose are pretty much the two areas that I refuse to do research in
> bwinton: jcranmer: That’s a pretty good policy
The compose window actually involves different pieces of software: one of them is responsible for assembling the message, and passing it to the sending logic. The other one is the actual composition UI, which includes a whole bunch of dialogs (e.g. inserting an image, inserting a link), as well as the central component, called the editor (the big blank area where you type your message). Different factors can explain the lack of activity in that part of the Thunderbird code:
- editor is notoriously hard to grasp – this is a vast, ancient piece of software, that didn’t quite move on as the rest of the gecko core kept improving (although this has been changing recently, thanks to Ehsan’s work),
- the assembling and sending logic is all-C++, which makes it hard for extension authors to interact with us, and for would-be contributors to help us,
- the composition UI involves a lot of (very old) files, most of which we cannot maintain, because
- Mozilla Messaging is extremely low on resources.
We’re currently exploring ways to relieve the pressure, and move on to a saner design for us. I’ve been working on an experiment that aims at tackling these pain points. It basically consists in replacing the standard XUL compose window with a tab written in XHTML that integrates CKEditor, and doing all the composition process in JS, upto the actual send that takes places in C++.
The potential benefits are as follows.
- We’d be able to move to a more maintainable architecture. Having the compose code written in JS would certainly enable us to do much more, and be much more extensible.
- We’d pave the way for having a pluggable editor. Right now, the code is assuming that the only part that sends messages is the compose window. Other people might want to send messages too (Thunderbird Air is one of them).
- We’d defer the maintainance burden of the composition UI – the insert image dialog, for instance – to a third-party. This means more bugfixing, more active development, from a project that is Thunderbird-friendly to boot. We’re not doing any active development on these anyway…
- We’ll certainly introduce tons of bugs. However, fixing bugs in CKEditor certainly sounds more doable than fixing bugs in the C++ editor components.
- We’d finally introduce the much-wanted “compose in a tab” feature.
This experiment has barely reached the point where it starts being actually usable. However, I figured out I might as well share it with the community so that we can gather initial feedback.
Some disclaimers apply.
- That extension actually requires Contacts for the autocomplete (a nice side-effect is that you can autocomplete more than two addresses for the same contact, ha!).
- This extension is an experiment. There’s a huge list of things it doesn’t do. Right now, it barely allows you to reply, forward, and edit/save drafts. It doesn’t take your preferences into account, it only sends html, not mixed mime emails. It has bugs. Lots of them.
- To make sure this works properly, you need to ensure in Tools > Accounts settings that for each of your accounts, in the “Composition and addressing” section, “Compose messages using HTML” is actually checked. Otherwise, you will send HTML markup as plain/text, which is usually a bad idea.
- This release targets Thunderbird 3.1. Because patches that enhance interaction between this new editor and the Thunderbird core will have to wait for 3.2, you will see a lot of errors in the Error Console.
- Support will be scarce. I am not a Mozilla Messaging employee, and I’m doing this on my spare time. So please be patient, check out the list of missing features on the GitHub Wiki, and don’t report a ton of bugs: I’m probably aware of them already :-).
Here’s a screencast:
I’m looking forward to hearing your thoughts on this!