Re: Summary of the situation with the composition process — thoughts wanted
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".
More information about the tb-planning