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

[Torgny Nyblom]

> 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.

@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/