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

[Sudhendu Roy]

On Thu, Mar 31, 2011 at 2:55 PM, Torgny Nyblom <kde at nyblom.org> wrote:

> > 2011/3/30 Thomas McGuire <mcguire at kde.org>
> >
> >> Hi,
> >>
> >> On Saturday, March 26, 2011 05:59:24 AM Torgny Nyblom 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.
> >> >
> >> > That means that to enable html replying, we need to change
> >> TemplateParser
> >> > _and_ replace QTextEdit (or any layer above that) with a html aware
> >> editor
> >> > component?
> >>
> >> Yes, both need to be done. The most important step is changing the
> >> TemplateParser to be HTML-aware.
> >>
> > Then next step then is to replace QTextEdit with some webkit component.
> >> That step is only needed because as Ingo said, "QTextEdit would have
> >> totally
> >> corrupted any mildly advanced HTML message". Not sure how bad QTextEdit
> >> is
> >> here. But anyway, without making the TemplateParser HTML-aware, there
> >> would
> >> be
> >> no mildly advanced HTML that could be corrupted :)
> >>
> >> Me and Torgny Nyblom discussed it on IRC too. Torgny was quiet happy
> >> with
> > the idea of preserving the code and add an editor for enriched text. We
> > can/should give user to choose between the type of message
> > (plain/enriched)
> > he want to receive. This can be handled by TemplateParser.
>
> Thomas and I had a chat last evening and the plan that arised was:
>
> 1: Fix the templateparser to be able to preserve HTML.
> 2: In KDEPIM::MessageComposer remove the KMeditor and make that into an
> abstract interface that the former KMeditor implements (for non webkit
> platforms) and make a new HtmlEdit component that also implements this
> interface.
> If any code can be shared between these two implementations then that
> should be in a protected method in the base class (interface).
>
> The scope (at least initially) in only usage inside the MessageComposer.
>
I totally agree to what has been planned :)

>
> @Thomas: did I miss anything?
>
> /Regards
> 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/
>
_______________________________________________
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/