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

Jonathan Protzenko jonathan.protzenko at gmail.com
Sun Jun 26 06:30:40 UTC 2011


On 06/21/2011 01:18 PM, Joshua Cranmer wrote:
> 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?
Your understanding of the situation is pretty good. I don't want to push 
this experiment further because I'm going the hacky route and this will 
soon be untenable for me. I just wanted to show a proof-of-concept. The 
main conclusions I have reached are:
- 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20110625/553a40ad/attachment.html>


More information about the tb-planning mailing list