Summary of the situation with the composition process — thoughts wanted
Jonathan Protzenko
:bwinton, :jb and I were discussing issues related to the composition process, and I thought I might as well post my summary of the situation here, so that other people can chime in. :ehsan should give us some insight on the situation, and I'm confident other people will have interesting things to say.
Below is a (lengthy) summary of the situation, and represents my own point of view. If I appreciated wrongly the situation, please do correct me asap.
---
The compose window in Thunderbird relies on three broadly defined components.
- 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.
- 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.
- 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.
- Given that we don't have that many resources to devote to the composition UI (2.), this would allow us to cheaply get an updated, more intuitive UI.
- Make the composition code more accessible to developers. Hacking into that C++ code is insanely hard, the entry cost is high, and it's scary. Writing it in JS would make it more concise, lighter, and more hackable. We could also drop large chunks of code that make no sense today : the C++ code goes great lengths to figure out the best encoding to sent the outgoing message with. In compose in a tab, I settled for UTF8 always, and saved myself a lot of trouble.
- Allow experimenting with new designs, such as compose in a
tab.
- This part doesn't change at all with my experiment.
- The Thunderbird UI is replaced by a CKEditor instance.
- This is where I come in.
- I rewrote this part in JS, and I've implemented most required actions. This is either code that determines the recipients depending on the composition mode, streams the draft to insert its body into the edition area, re-uses the attachments from the draft, or the forwarded message, etc; or code that performs less pleasant tasks, such as rewrapping the text, quoting and rewrapping, or convert html to plaintext (do you realize that the component in Thunderbird that does html -> plaintext conversion for quoting is not even scriptable?).
- This part heavily relies on an <editor> being
available, so I had to fake myself into a nsIEditor and a
nsIEditorMailSupport. This roughly works, but I had to resort
to the most vicious hacks to get this done (more details in an
appendix).
- 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).
- The Herculean undertaking that this represents. There are zillions of options and of possible behaviors; more than a sane man would get crazy trying to implement them all. I even regularly discover some new options myself: the thing with multiple identities for one single account, all preferences regarding composition (top-posting vs bottom-posting, signatures above/below the quote, signature / no signature, quote / no quote, font, color, html, plaintext, html + plaintext, utf8, no utf8), s/mime, attachment reminder, MDN, DSN, autosave, different composition modes (edit draft, reply, reply all, new, etc. I think there are 14 of them), initial attachments, were we called through mapi, command-line, drag&drop of attachments from: the filesystem, another email, an URL... I believe some of these options should go away, even if some users are going to crucify us for this. I don't think we have the manpower to undertake a rewrite of the composition process and still afford to keep that variety of customizations.
- There are hidden invariants all over the place. Specific
design patterns that oblige you to re-use a specific object, and
modify it in place. Very specific calling conventions. Hidden
state that require you to call just the magic function so that
it will fail after 10 lines because you're not implementing the
right interfaces, but will still set the global variable to the
right value. More generally, the expectation that the only place
we will ever compose messages from is the composition window.
jonathan
Appendix 1 : the thing with global variables
The workflow for sending a message goes like this.
- nsMsgComposeService creates a new nsMsgCompose instance, and creates a new composition window (all from C++),
- nsMsgCompose pokes into the editor from the new window, initializes it with various parameters, sets its mode to html or plaintext, etc, and sets a whole bunch of global variables,
- nsMsgCompose assembles all the parts, queries the editor, and passes the control flow to nsMsgSend
- nsMsgSend still pokes into the nsEditor (more specifically, nsEditorMailSupport).
This all implies the existence of a composition window. I can't assemble the parts myself and talk directly to nsMsgSend because half the interfaces there are [noscript]. So what I had to do is use the SendMsg function from nsMsgCompose that assembles the parts and moves on to nsMsgSend.cpp. However, there are two global variables that have to be set if you want to send anything besides plaintext. These two global variables are only set when initializing the classic compose window. So I had to fake myself into a classic compose window, and implement just enough interfaces so that the two variables are initialized correctly, and then fail early. nsMsgCompose then *thinks* it's dealing with a regular compose session, and goes on with the right editor + html settings. This is wicked. (The two variables control whether there's html or plaintext (m_composeHTML) and if there's an editor that should be poked (m_editor)).
�
I managed to hack around all these limitations, and somehow build a clean API on top of that; it took me months to improve it over and over; I consider this an achievement in itself. I'm even able to send attachments through JS! This still amazes me. Most of the code went into the quick reply feature of Thunderbird Conversations, and this is where I keep polishing the code over and over. However, the question of the editor UI still remains open.
Tanstaafl
> The Herculean undertaking that this represents. There are zillions of
> options and of possible behaviors; more than a sane man would get crazy
> trying to implement them all. I even regularly discover some new options
> myself: the thing with multiple identities for one single account, all
> preferences regarding composition (top-posting vs bottom-posting,
> signatures above/below the quote, signature / no signature, quote / no
> quote, font, color, html, plaintext, html + plaintext, utf8, no utf8),
> s/mime, attachment reminder, MDN, DSN, autosave, different composition
> modes (edit draft, reply, reply all, new, etc. I think there are 14 of
> them), initial attachments, were we called through mapi, command-line,
> drag&drop of attachments from: the filesystem, another email, an URL...
> I believe some of these options should go away, even if some users are
> going to crucify us for this. I don't think we have the manpower to
> undertake a rewrite of the composition process and still afford to keep
> that variety of customizations.
I'm excited to see movement on the compose editor, and I totally
understand what you are saying about how much work is involved...
Maybe it was just a bad choice of words above, but, rather than say
'some of these options should go away, even if some users are going to
crucify us for this', why not word it like:
"We need to decide on a bare necessity subset of the above options that
everyone (devs) agree are absolutely necessary, but we will be
implementing things such that additional options can be easily added,
both by the core devs in future updates as time/resources permits, and
sooner if desired by extension developers."
The way you worded it above makes it sound like a permanent loss of
options...
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning
Joshua Cranmer
- The Herculean undertaking that this represents. There are zillions of options and of possible behaviors; more than a sane man would get crazy trying to implement them all. I even regularly discover some new options myself: the thing with multiple identities for one single account, all preferences regarding composition (top-posting vs bottom-posting, signatures above/below the quote, signature / no signature, quote / no quote, font, color, html, plaintext, html + plaintext, utf8, no utf8), s/mime, attachment reminder, MDN, DSN, autosave, different composition modes (edit draft, reply, reply all, new, etc. I think there are 14 of them), initial attachments, were we called through mapi, command-line, drag&drop of attachments from: the filesystem, another email, an URL... I believe some of these options should go away, even if some users are going to crucify us for this. I don't think we have the manpower to undertake a rewrite of the composition process and still afford to keep that variety of customizations.
Rewriting compose in one batch would be pure insanity. Applying lessons from my current rewriting work with DXR, if you decide that you want to fix the entire flow of the code, it is far, far better to take each step in process. While it's admirable that you've done so much work, it would probably be better to slice this up into smaller steps and rewrite each step individually over the course of weeks, months, even years (sadly).
As I understand it, the high-level overview of what happens with composition is the following:
1. The codebase realizes it needs to open up an editor
2. The window is created (or reused, yuck) and fully initialized.
2.5 Initial message contents and parameters are set.
3. The user (un)happily edits their message via the UI--most code here is fairly contained within the editor
4. The editor's contents become serialized into the message envelope
5. The code sends the message envelope
If we can agree on what the workflow should look like, I think the following plan of attack would work best:
1. Define where the boundaries between steps are and what information should be passed. Ideally this information should be minimal.
2. Modify the current code to add in the workflow boundaries
3. Modify the code to require only the information being passed through the boundaries
4. Start replacing broken code with clean, new working code, one stage at a time.
Of the features of which you say that we have too many, most of them basically boil down to either saying "I want the initial message to look like this" or "I want to set this parameter before sending"... if we can cleanly separate workflow stages, it should be possible to get by without sacrificing any of those.
But, at the very least, I think we need a sense of what we want the compose code to look like in Thunderbird ∞, so we can produce a roadmap and start implementing it. It sounds like this is what you're volunteering to help do?
-- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Ehsan Akhgari
<jonathan....@gmail.com> wrote:
> 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.
Just to correct a bunch of facts, kaze has not started yet, and the
caret code lives outside of the editor (as we support carets even for
non-editable areas).
> 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.
FWIW, I have not looked at that code, and it's not on my list (mainly
because it's not used in Firefox).
> Given that we don't have that many resources to devote to the composition UI
> (2.), this would allow us to cheaply get an updated, more intuitive UI.
ckeditor is way more than just the UI for the editor.
> Make the composition code more accessible to developers. Hacking into that
> C++ code is insanely hard, the entry cost is high, and it's scary. Writing
> it in JS would make it more concise, lighter, and more hackable. We could
> also drop large chunks of code that make no sense today : the C++ code goes
> great lengths to figure out the best encoding to sent the outgoing message
> with. In compose in a tab, I settled for UTF8 always, and saved myself a lot
> of trouble.
Is that a good choice? For example, are there mail clients which are
not capable of correctly handling UTF-8? (It's not a rhetorical
question, I don't really know).
> I rewrote this part in JS, and I've implemented most required actions. This
> is either code that determines the recipients depending on the composition
> mode, streams the draft to insert its body into the edition area, re-uses
> the attachments from the draft, or the forwarded message, etc; or code that
> performs less pleasant tasks, such as rewrapping the text, quoting and
> rewrapping, or convert html to plaintext (do you realize that the component
> in Thunderbird that does html -> plaintext conversion for quoting is not
> even scriptable?).
> This part heavily relies on an <editor> being available, so I had to fake
> myself into a nsIEditor and a nsIEditorMailSupport. This roughly works, but
> I had to resort to the most vicious hacks to get this done (more details in
> an appendix).
So, this would mean that we have to maintain two versions of the same
code in the future (one in ckeditor, the other in editor/)? Or are
you also going to change the SeaMonkey usages of this code?
Also, nsIEditor is not going to remain in its current shape for a long
time, so I wouldn't design any APIs on top of it if I were you. :-)
> There are many problems, though.
>
> CKEditor tries to be cross-platform
Correction: cross-browser.
> 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).
What are the upsides of taking ckeditor's code, besides getting a new
shiny and sexy editor UI really fast? What are the maintenance costs?
Do they have tests? Do you have plans to address these downsides?
(Note that some of them, such as ckeditor trying to implement its own
editing features are pretty intrinsic parts of that project.)
> The Herculean undertaking that this represents. There are zillions of
> options and of possible behaviors; more than a sane man would get crazy
> trying to implement them all. I even regularly discover some new options
> myself: the thing with multiple identities for one single account, all
> preferences regarding composition (top-posting vs bottom-posting, signatures
> above/below the quote, signature / no signature, quote / no quote, font,
> color, html, plaintext, html + plaintext, utf8, no utf8), s/mime, attachment
> reminder, MDN, DSN, autosave, different composition modes (edit draft,
> reply, reply all, new, etc. I think there are 14 of them), initial
> attachments, were we called through mapi, command-line, drag&drop of
> attachments from: the filesystem, another email, an URL... I believe some of
> these options should go away, even if some users are going to crucify us for
> this. I don't think we have the manpower to undertake a rewrite of the
> composition process and still afford to keep that variety of customizations.
> There are hidden invariants all over the place. Specific design patterns
> that oblige you to re-use a specific object, and modify it in place. Very
> specific calling conventions. Hidden state that require you to call just the
> magic function so that it will fail after 10 lines because you're not
> implementing the right interfaces, but will still set the global variable to
> the right value. More generally, the expectation that the only place we will
> ever compose messages from is the composition window.
I'm in general all in favor of simplifying things. But reading this
message, I got the feeling that we're attacking this problem
backwards. Implementation constraints should not really dictate the
features of a product. I think we should try to determine which ones
of those features we want to keep and which ones we want to throw
away, and then model our implementation around those decisions.
Cheers,
--
Ehsan
<http://ehsanakhgari.org/>
Joshua Cranmer
> Is that a good choice? For example, are there mail clients which are
> not capable of correctly handling UTF-8? (It's not a rhetorical
> question, I don't really know).
I have heard that some Japanese mobile phones are not capable of
understanding mails written in UTF-8 and expect Shift-JIS instead.
Actually, this is one feature that I would be happy to see go: I
occasionally drop in Unicode characters into my messages all the time,
and the editor should upgrade to UTF-8 automatically if that is the case
instead of going "Oy, you're not using UTF-8, you can't do that, unless
you want me to make you do UTF-8?"
--
Joshua Cranmer
News submodule owner
DXR coauthor
Kent James
> features of a product.
implementation constraints, certain things would not get done. My New
Account Types (SkinkGlue) discussion was a good example, where I had a
less than perfect but available solution, and by the time we had
everyone say what the ideal feature set would be, there was no
reasonable chance it would get implemented.
Sometimes the best is the enemy of the good. Don't know if that applies
to composer or not.
rkent
David Bienvenu
Enabling new ways of creating and sending messages is important. Yes, nsIMsgSend has a lot of [noscript] methods but if spending the couple days it would take to make it entirely scriptable would be helpful, we should do it.� In general, I'm all in favor of making things scriptable. And now that we have a rapid release schedule, there's less reason to work around non-scriptable interfaces and instead just fix them.� There are very few interfaces that are noscript for a good reason anywhere in the mailnews backend.
And once the interfaces are scriptable, if someone wants to implement nsIMsgSend in js, then they can, and we can throw out the mess that is nsMsgSend.cpp. Yes, the interface could be simplified and features thrown out, but I don't think doing that should block innovation like Conversations or compose in a tab. If it would take a month to make it scriptable, then it would be different, but it looks fairly straightforward to me.
Re just sending in utf8, yeah, that's enormously appealing. I'd love to hear from people in other locales (e.g., Japan) if there's any reason not to always do that.
Drag-dropping images into a compose window is a lot easier than using the menu commands.
- David
On 6/21/2011 11:35 AM, Jonathan Protzenko wrote:
Joshua Cranmer
> Re just sending in utf8, yeah, that's enormously appealing. I'd love
> to hear from people in other locales (e.g., Japan) if there's any
> reason not to always do that.
> This is critical for Japanese users. Some Japanese are really really
> conservative about the mail format. Some people even filter the all
> non-ISO-2022-JP messages. (It is an efficient spam filter for those
> who are not intrested in foreign messages.) Others believe that they
> can't use UTF-8 in mail body unless they have a private agreement
> each other. Moreover, some Japanese mobile phones and Webmails still
> do not cope with UTF-8.
That comment is 2 years old, but it also brings up a point that some people may be using charsets as (a really, really poor) proxy for spam detection...
JoeS
The compose window in Thunderbird relies on three broadly defined components.
- 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.
- 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.
- 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.
--
JoeS
Tanstaafl
> Enabling new ways of creating and sending messages is important. Yes,
> nsIMsgSend has a lot of [noscript] methods but if spending the couple
> days it would take to make it entirely scriptable would be helpful, we
> And now that we have a rapid release schedule, there's less reason to
> are very few interfaces that are noscript for a good reason anywhere in
> the mailnews backend.
About the only thing I can contribute to this conversation is this...
Thunderbird needs these ancient-code problem areas (mainly the composer)
fixed far more than it needs sexy new features (like integrated chat
support).
Guys - it is first and foremost an email client - if you need to spend
*all* of your resources (except for what is needed to keep up with the
Gecko updates) for 3 solid *months* fixing the composer, then *just do
it*. Then, once it is done, you can start working on the sexy new
feature of the day.
Composing HTML messages (especially replying to them) in Thunderbird is
one of the most frustrating experiences I have ever had.
Ehsan Akhgari
> On 6/21/2011 2:36 PM, Ehsan Akhgari wrote:
>>
>> Implementation constraints should not really dictate the
>> features of a product.
>
> Welcome to the TB world of very limited resources. If we do not consider
> implementation constraints, certain things would not get done. My New
> Account Types (SkinkGlue) discussion was a good example, where I had a less
> than perfect but available solution, and by the time we had everyone say
> what the ideal feature set would be, there was no reasonable chance it would
> get implemented.
>
> Sometimes the best is the enemy of the good. Don't know if that applies to
> composer or not.
That is all true, but we should also make sure not to dig ourselves
into a hole which we can't escape from later on.
--
Ehsan
<http://ehsanakhgari.org/>
John Hopkins
> On Tue, Jun 21, 2011 at 6:10 PM, Kent James<ke...@caspia.com> wrote:
>> On 6/21/2011 2:36 PM, Ehsan Akhgari wrote:
>>> Implementation constraints should not really dictate the
>>> features of a product.
>> Welcome to the TB world of very limited resources. If we do not consider
>> implementation constraints, certain things would not get done. My New
>> Account Types (SkinkGlue) discussion was a good example, where I had a less
>> than perfect but available solution, and by the time we had everyone say
>> what the ideal feature set would be, there was no reasonable chance it would
>> get implemented.
>>
>> Sometimes the best is the enemy of the good. Don't know if that applies to
>> composer or not.
>>
>> That is all true, but we should also make sure not to dig ourselves
>> into a hole which we can't escape from later on.
>>
makes a lot of sense to me. Conversely, there's the "a large chasm
can't be leapt across in several small jumps" argument. Depends on the
feature.
John
Jonathan Protzenko
> The way you worded it above makes it sound like a permanent loss of
> options...
staff, this profusion of options is costing us a lot. Can you imagine
how many hours I had to spend to make sure Thunderbird Conversations
complies with every possible setting in the Thunderbird world? I
discover new options every week. It took me one year to interact with
all the oddities that exist in the community. And yes, there are people
who are using these options. But these people know how email works, and
they know how to reach us (and me) when their favourite options breaks.
This situation is close to untenable. This is why I'm spending hours and
hours polishing Thunderbird Conversations, and why having compose in a
tab replicate all the options of the current composition workflow seems
out of reach for me.
This will sound blunt to you, and you (and probably others) will feel
outraged. But I do think we need to drop some options. I'm not trying to
troll, although this seems to be the mood right now in the community.
What I'm trying to say is: we need to be pragmatic. And my experience,
and the way I feel things is there's too many options.
Kind regards,
jonathan
Jonathan Protzenko
1. The codebase realizes it needs to open up an editor
2. The window is created (or reused, yuck) and fully initialized.
2.5 Initial message contents and parameters are set.
3. The user (un)happily edits their message via the UI--most code here is fairly contained within the editor
4. The editor's contents become serialized into the message envelope
5. The code sends the message envelope
(...)
But, at the very least, I think we need a sense of what we want the compose code to look like in Thunderbird ∞, so we can produce a roadmap and start implementing it. It sounds like this is what you're volunteering to help do?
- it is easy, and feasible, to rewrite the composition steps 2, 2.5, and 3 using JS and an external UI for the editor,
- CKeditor doesn't seem to fit that well, we'd probably need to write our own, to refresh the old one, or find another one better suited for the task,
- there's a lot of complexity, but if we agree on a minimal subset of features that we need to have, and progressively clean up the code, it will be feasible to offer a replacement (assuming we solve the previous point). As David said, removing the [noscript]s is actually feasible, and we'd be able to replace nsMsgCompose.cpp piecewise. It's just that I didn't want to start hacking Thunderbird without further reflecting in the issue.
What I need is:
- commitment towards this direction: "yes, this is something we need to do, let's have more people working on it", otherwise I don't feel like carrying the rewrite on my own, I don't have a broad enough set of skills (I'm bad at UI and UX, for instance), and this is too much work for a single person;
- a solution for the editor UI issue. Both rkent and ehsan made good points, rkent saying that "yes we have limited resources, so relying on an external editor might relieve the burden for us" (rephrasing here), and ehsan saying (rightly) that ckeditor might bring more problems than it solves.
Assuming we find a way to solve both problems above, I would certainly do my best to see this happen.
Thanks to everyone for the insights,
jonathan
Jonathan Protzenko
Thanks for sharing your thoughts.
>> Given that we don't have that many resources to devote to the composition UI
>> (2.), this would allow us to cheaply get an updated, more intuitive UI.
> ckeditor is way more than just the UI for the editor.
>
> (...)
> What are the upsides of taking ckeditor's code, besides getting a new
> shiny and sexy editor UI really fast? What are the maintenance costs?
> Do they have tests? Do you have plans to address these downsides?
> (Note that some of them, such as ckeditor trying to implement its own
> editing features are pretty intrinsic parts of that project.)
Well, yes. We have these long-standing bugs, the composition UI is not
evolving (talking about comm-central/editor here), and we'd like to be
more attractive to users. Please keep in mind that in the present state,
we *do not have any resources to devote to this area*. It is fairly
natural that we should seek to re-use some 3rd-party code. However,
after the arguments you've brought, I start to feel like CKEditor might
not be the best solution after all.
Given all the constraints above, can you think of any readymade editor
that we could possibly reuse? Are there any plans on the Gecko/Firefox
side to write such a thing? An embeddable editor for the web with a
pre-packaged UI could be highly beneficial... (Only talking about the
associated UI and dialogs here).
Cheers,
jonathan
Jonathan Protzenko
> It took me one year to interact with all the oddities that exist in
> the community.
Ehsan Akhgari
Unfortunately I'm not aware of any editor widget projects which can be
a drop-in replacement for the editor UI in Thunderbird. On the Gecko
side of things, we do not plan on providing built-in UI for the editor
in the near future.
Cheers,
--
Ehsan
<http://ehsanakhgari.org/>
Jon Grossart
I've been following the tb-planning list for awhile out of curiosity and saw you were looking for other Javascript editors.� In case you didn't run across these, I found a few options:
http://www.queness.com/post/212/10-jquery-and-non-jquery-javascript-rich-text-editors
Specifically, maybe TinyMCE and YUI (although probably heavier in framework) might be valid options.� Still cross platform, but maybe lighter than ckeditor.
Here is another older list:
http://www.webdesignerdepot.com/2008/12/20-excellent-free-rich-text-editors/
Thanks,
Jon
Joshua Cranmer
> - commitment towards this direction: "yes, this is something we need
> to do, let's have more people working on it", otherwise I don't feel
> like carrying the rewrite on my own, I don't have a broad enough set
> of skills (I'm bad at UI and UX, for instance), and this is too much
> work for a single person;
Part of the idea behind the progressive rewrite is to allow some
particularly hellish pieces of backend code to be rewritten by people
who don't have the comfort to handle the UI portions of the rewrite.
Definitely, I am supportive of the idea of a major compose rewrite, as
compose is one of the areas that (IMHO) critically needs to be
rewritten. I would volunteer to help, but time is an asset I find too
often in short supply right now...
At the very least, it seems prudent to have a roadmap of "this is what
we want the API to look like, and we will move chunks over to it as time
goes on".
> - a solution for the editor UI issue. Both rkent and ehsan made good
> points, rkent saying that "yes we have limited resources, so relying
> on an external editor might relieve the burden for us" (rephrasing
> here), and ehsan saying (rightly) that ckeditor might bring more
> problems than it solves.
I recall listening in to a debate on m.d.platform about potential
editors for one of the webtool thingies people are working. The general
conclusion I seem to recall is that the built-in gecko editor is pretty
much the only editor that has a decent accessibility story. So it sounds
like either way, we'll have major resource issues. As someone who likely
won't be the person working on this, it seems prudent to at least
prototype an external editor and see how much work that can entail, so
as best to determine how much work integrating another editor would be.
--
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
_______________________________________________
Karsten Düsterloh
> * Make the composition code more accessible to developers. Hacking
> into that C++ code is insanely hard, the entry cost is high, and
> it's scary. Writing it in JS would make it more concise, lighter,
> and more hackable.
I beg to differ.
C++ (or rather: C, when talking about libmime's core) and JS are just
different languages for different purposes. Every language is "scary" to
those who are not proficient with it. (Including me, of course!)
We have structural problems caused by negligence,
we don't have a language problem.
The biggest disadvantage of JS is still speed (due to being a
interpreter language), but this, too, is a not an issue with today's
hardware anymore, even without JIT.
> We could also drop large chunks of code that make no sense today :
> the C++ code goes great lengths to figure out the best encoding to
> sent the outgoing message with. In compose in a tab, I settled for
> UTF8 always, and saved myself a lot of trouble.
Yes, that may be non-issue today when composing, but wrt Germany, many
mails are still written in iso-8859-15 or even windows-1252.
> Allow experimenting with new designs, such as compose in a tab.
The latter is not bound to a specific language. ;-)
Karsten
Jim
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
Robert Kaiser
> 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.
Note that Ian Neal is working on making the Composer (including message
compose) toolbars customizable for SeaMonkey and has been fixing a few
strange things in shared editor/ui code as preparatory work, I guess
both sides can profit from that work in the end and Ian would be glad
about help on this.
Cheers,
Robert Kaiser
JoeS
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.
I did this completely with Thunderbird. To get an understanding of the problems..try snipping this section, and editing it so that the Gecko appears floated to the right instead of the left. You might get enlightened by the effort. You can send the result to my email address, rather than here, if you wish.
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".
That would be #1 on the list.
https://bugzilla.mozilla.org/show_bug.cgi?id=250539
[MailNews Core] - New paragraph (e.g. list) clears formatting, does not respect font prefs for HTML messages [All]
21 Dups 44 cc's orig bug 2004-07-09
I compiled this list about a year and a half ago, so the Dups, and CC counts are I'm sure incorrect/invalid or whatever.
https://bugzilla.mozilla.org/show_bug.cgi?id=380372
[Thunderbird] - Attachment error when saving twice as draft a mail template containing an inline image [All]
3 Dups 23 cc's orig bug 2007-05-11
https://bugzilla.mozilla.org/show_bug.cgi?id=224733
[MailNews Core] - escape issues with mailbox urls in the compose window [Win]
7 Dups 10 cc's orig bug 2003-11-04
Related
https://bugzilla.mozilla.org/show_bug.cgi?id=351109
[MailNews Core] - Reply/Forward/Edit of .EML file corrupts image URL (bad escape) [All]
Related:
https://bugzilla.mozilla.org/show_bug.cgi?id=429846
[Thunderbird] - Copy and Paste breaks mail-internal links <a href="#anchor"> (private profile links get sent, broken) [All]
https://bugzilla.mozilla.org/show_bug.cgi?id=154836
[MailNews Core] - Image sent embedded is not used for the style sheet. CID: url types doesn't work for CSS [All]
4 Dups 11 cc's orig bug 2002-06-28
https://bugzilla.mozilla.org/show_bug.cgi?id=380372
[Thunderbird] - Attachment error when saving twice as draft a mail template containing an inline image [All]
4 Dups 23 cc's orig bug 2007-05-11
https://bugzilla.mozilla.org/show_bug.cgi?id=247816
[Core:Editor] - Adding float style causes some pre-existing style attributes to be dropped [All]
1 Dup 5 cc's orig bug 2004-06-20
Note: the advanced editor is a feature that most users simply don't know about.
It's difficult to use, gives no syntax help, but if you know a little CSS, works fine, except for the above bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=31052
[MailNews Core] - Send Page received with added text in color. [All]
13 Dups 22 cc's orig bug 2000-03-08
Related:
https://bugzilla.mozilla.org/show_bug.cgi?id=341059
[MailNews Core] - MIME messages should be displayed using separate DOM documents for each part [All]
A couple of those might actually not be Core/Editor but Libmime or the way we render the message as one big document.
--
JoeS