[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    KMail HTML GSoC project question on QtWebKit usage
From:       Geza Kovacs <gkovacs () MIT ! EDU>
Date:       2009-04-01 0:14:11
Message-ID: 1238544851.14306.48.camel () m12-182-3 ! mit ! edu
[Download RAW message or body]

Hi Thomas et al,

The project described at
http://techbase.kde.org/Projects/Summer_of_Code/2009/Ideas#Project:_Improvments_in_KMail.27s_HTML_support \
proposes a variety of solutions for KMail's HTML support. Given the complexity of \
HTML, relying on a well-established rendering engine seems like the best long-term \
solution in terms of maintainability, though using QTextDocumentWriter's OpenDocument \
support to compensate for features missing in HTML seems like an ugly hack, and \
doesn't seem to solve the goal of having unrecognized HTML tags "pass through" KMail \
unaltered. Thus, I'd prefer the approach of building an editor widget (or perhaps \
KPart, for potential usage in a WYSIWYG HTML editor) based on QtWebKit.

However, given that QtWebKit hasn't apparently been made a dependency in
KDE, with the non-default WebKit KPart for Konqueror being to my
knowledge the only software in KDE that currently depends on WebKit, I
was wondering if this dependency introduction is indeed considered
acceptable. If not, I was wondering if perhaps the same (constructing an
editor widget or perhaps KPart) might be doable on top of KHTML. While
KHTML doesn't seem to have an equivalent to the contentsChanged signal
to support direct textual input by the user, I was thinking that perhaps
some Javascript-based workarounds, combined with standard HTML forms,
might allow for KHTML to be used instead.

Of course, it seems to me that in the long term QtWebKit will eventually
prevail over KHTML, so if the additional dependency is indeed not an
issue and it's acceptable to simply reimplement the editor window as a
QWebView then that would probably be the most elegant way to do it - I
merely wished to know if that would be an acceptable approach.

Regards,
Geza

 
> > Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]