Re: Summary of the situation with the composition process — thoughts wanted
joesab2005 at gmail.com
Tue Jun 21 22:24:43 UTC 2011
On 6/21/2011 2:35 PM, Jonathan Protzenko wrote:
> The compose window in Thunderbird relies on three broadly defined
> 1. The <editor> component from Gecko; it handles the editable area,
> i.e. where you type your message, the caret, what happens when you
> hit enter, the DOM tree, etc. The code lives in
> comm-central/mozilla/editor/. :ehsan and :kaze are working on it
> if I'm not mistaken.
> Ehsan and Kaze are working on it , but not from the POV of a mail
> editor.Although I think that almost anything that can be done in a
> web page should be possible in an email. That assumes that CSS is
> allowed in emaill...an assuption that has been vehemently opposed
> in the past. If you look at the horrible code produced by the MS
> word html editor (and deemed to be acceptable media) surely we
> should loosen our "stance" on including/encouraging good HTML/CSS.
> 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*.
> If you think inserting an image is not intuitive, try using the
> /Advanced Editor /to add some inline styles. Oh, to get into that
> editor, you just double click on the image and choose "advanced"
> You can add inline styles, but you must know the exact correct
> syntax. There is no help there at all, and properties are removed
> if you attempt to edit pre-composed code.
> 3. The code for setting up a compose session and sending the message.
> It's all c++, and I'm thinking about
> comm-central/mailnews/compose/src/, most specifically
> nsMsgCompose.cpp and nsMsgSend.cpp.
> * The code first initializes the composition window, does a lot
> of magic, sets up all the composition fields, both visible and
> hidden (recipients, subject, headers, quoted & reformatted
> text, signature, MDN, etc.). It talks to the nsIEditor that
> the <editor> implements to setup html / plaintext editing, the
> encoding, etc.
> * Then, nsMsgSend.cpp kicks in, walks the DOM tree, figures out
> which images should be attached, determines whether html +
> plaintext or just plaintext should be sent, changes the src
> attributes live in the <editor> instance so that <img
> src="blah.jpg"> becomes <img src="cid:whatever"> and then
> serializes it all according to the right encoding, wraps it,
> sends it.
> Yes, the CID whatever is problematic from a couple of
> different aspects. CSS background-image comes to mind. I think
> the problem there is Libmime. A few yaers back, one of the
> veteran core devs started to look at that, but withdrew
> because that code /"Made his eyes bleed" ;-) /
Thanks for bringing this subject up. But please remember that folks have
been fighting these editor quirks for years and coming up with their
own little work-arounds. Any feature that you prune out, might just be
that needed feature.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning