[Kde-pim] Re: lead for GSoC proposal on HTML support to KMail

[Torgny Nyblom]

On Saturday 26 March 2011 15.06.40 you wrote:
> On Sat, Mar 26, 2011 at 11:29 AM, Torgny Nyblom <kde at nyblom.org> wrote:
> > On Friday 25 March 2011 20.53.15 Ingo Klöcker wrote:
> > > On Friday 25 March 2011, Torgny Nyblom wrote:
> > > > On Friday 25 March 2011 15.59.40 Thomas McGuire wrote:
> > > > [...]
> > > > 
> > > > > The first thing would be making replying/forwarding preserve
> > > > > the
> > > > > HTML format, which is actually independent of the GUI
> > > > > editor.
> > > > > Right now when replying/forwarding a message, a new message
> > > > > that
> > > > > is the reply/forward is created. That new message already
> > > > > lacks
> > > > > the HTML part, which is the main problem in the whole story.
> > > > > So
> > > > > first KMail needs to be fixed to include a HTML part in
> > > > > replies/forwards.
> > > > 
> > > > Would I be wrong if I say that the culprit is
> > > > TemplateParser::messageText() as that calls
> > > > TemplateParser::asPlainTextFromObjectTree()
> > > 
> > > You are right in that requesting the plain text is the reason for
> > > the
> > > loss of the HTML. But you are wrong in saying that
> > > TemplateParser::messageText() is to blame for this.
> > > TemplateParser::messageText() didn't have another choice because
> > > QTextEdit would have totally corrupted any mildly advanced HTML
> > > message.
> > 
> > Does that mean if we replace the  present QTextEdit, then we need not
> 
> request the plain text? So by simply replacing text editor we can solve both
> the problem of requesting HTML text as well as forwrding/replying the
> messages. Am I right?

That is what I think, yes. But I guess we still need the option of getting the 
plain text if a plain text reply is requested.

/Torgny
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/