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

[Ingo Klöcker]

On Thursday 31 March 2011, Torgny Nyblom 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.

What non-webkit platforms do you have in mind? Windows Mobile 6.5 (or 
whatever it's called)? Do we really need to stay compatible with this? 
Do you have any other non-webkit platforms in mind? I cannot imagine any 
relevant platform which would have Qt + kdelibs + kdepimlibs + Kontact 
but not webkit.

What we really need to avoid is superfluous work. We don't have any man-
power to waste by making useless abstractions. Using an abstract 
interface for the editor was already tried many years ago. The idea was 
quickly abandonned because apparently nobody really needed this.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20110331/63e1b41f/attachment.sig>
-------------- next part --------------
_______________________________________________
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/