Re: Summary of the situation with the composition process — thoughts wanted

Jim squibblyflabbetydoo at gmail.com
Wed Jun 29 23:33:58 UTC 2011


Well, I promised I'd try to reply to this, so here goes...

On 06/21/2011 01:35 PM, Jonathan Protzenko wrote:
>  2. The editor UI: all the small buttons to insert an image, set text in
>     bold, italics, etc. The code lives in comm-central/editor/ui. It's
>     horrible code, that hasn't changed for the past 10 years, and unlike
>     wine, it doesn't get any better with age. AFAIK, no one's working on
>     it, and we definitely need help with it. The number of steps
>     required to merely insert an image is complete nonsense, and the
>     process is *not intuitive*.

Much of the stuff in the editor UI could probably be worked on, 
independent of any backend changes. There are some really obvious places 
that we could improve that probably wouldn't take a whole lot of effort 
or specialized knowledge. Some simple projects would be to make the 
formatting toolbar customizable, or to make the "Insert" menubutton into 
a dual-button that defaults to inserting an image.

As I recall, the composer also tries to reuse windows (presumably for 
performance). We could also work to remove that, which would probably 
make life easier for Thunderbird developers and add-on authors.

>   * CKEditor tries to be cross-platform and hence overrides many builtin
>     <editor> features, making them slower and more error-prone. For
>     instance, CKEditor will have its own handling of the <Enter> key,
>     and will break the DOM tree on its own, move the caret... CKEditor
>     has its own spellchecking also. CKEditor is very much heavyweight,
>     takes seconds to load, and doesn't necessarily fit well as the UI
>     for a mail editor (issues with <blockquote>s).

Having followed your compose-in-a-tab project off and on, I was always 
hoping in the back of my mind that you'd drop CKEditor. Ehsan has 
probably explained better than me, but I think we'll lose a lot of 
useful features (and performance) by relying on a cross-browser editor 
instead of working on our own. Even if we don't totally rewrite the 
editor UI, I think there are plenty of places where we can easily 
improve upon it.

The main reason I haven't bothered (and, I suspect, why many other devs 
haven't) is that I use the plain text editor. To be honest, I'm not even 
really sure what the specific problems people have with the composer are 
(aside from backend issues); you mentioned a few, but I'm sure there are 
more out there. Having a full list of these problems would help 
enormously, even if we just focused on frontend issues for the time 
being. If we had a list like that, I would probably be able to fix some 
of the issues. Even though that might not make the composer "great", it 
would at least make it "better".

- Jim



More information about the tb-planning mailing list