[Bug 86423] Ability To Reply To HTML Email With Same HTML Format As It Was Received

[Thomas McGuire]

https://bugs.kde.org/show_bug.cgi?id=86423





--- Comment #126 from Thomas McGuire <mcguire kde org>  2009-12-13 12:00:47 ---
Ah, a technical discussion now, that is much better :)
Replying to Jason's comment 124 now.

It is not true that the QTextEdit class didn't change since Qt 3.0. It got a
major overwork for Qt 4, which includes the QTextDocument and QTextEdit
separation, and much work on the layouting. It actually was completely
rewritten and the framework is called Scribe.
The HTML subset supported by QTextEdit can be found at
http://doc.trolltech.com/4.6/richtext-html-subset.html.

However, I agree that QTextEdit's HTML support is very limited when compared to
WebKit, and having a full WebKit editor is better. What I'd like to see at the
same time is porting the KMail reader from KHTML to WebKit as well, since
loading two HTML rendering engines is too much (especially when running GDB).

Regardless of having a WebKit based editor (which would be preferable) or a
QTextEdit based one, the basic work needed to be done before that is still the
same: Change the template parser to create multipart/alternative messages that
include the original HTML when replying or forwarding. Once that is done, the
HTML support is there. The composer already supports editing HTML messages, try
 right-clicking one and choosing "Edit Message". The issue is just that the
template parser doesn't provide multipart/alternative messages when
replying/forwarding (and that QTextEdit's HTML support is limited, of course).

When I said a WebKit based composer is too much work, I meant it is too much
work for _me_. That just means _I_ will not work on that, but I would be glad
if somebody else does that. However, don't underestimate the work that needs to
be done for this, QTextEdit and the derived classes have quite many features
that need to be implemented in the WebKit based editor as well. Mostly little
things like quote coloring, paste/drop support, spellchecking, many
cursor-based operations, etc, but this adds up, and this is why I said it is
too much work (for me). The normal non-HTML editing features in the
WebKit-based editor need to be as good as they are currently.
I am pretty sure this can not just be done "in a couple of hours of work".

> The idea that it is "too much work" to move to Webkit for editing, is solely
> because of the horrible API design of the KMail composer - no other reason. I
> know this because I have tried to do this port myself. The Komposer API is a
> huge mess, none of it is properly abstracted - this is why it is nearly
> impossible to move outside of QTextEdit.

Hmm, I wouldn't say the composer has horrible API design that makes moving to a
WebKit-based editor much of a problem. True, KMComposeWin is a big scary class,
but the actual editor is in a separate class, KMComposerEditor, which
(indirectly) inherits from QTextEdit.
Could be that it was worse in KDE3 times, I remember some nasty "KEdit" classes
there.

One last thing I want to add: If anybody wants to work on this, please do it in
the akonadi-ports branch (branches/work/akonadi-ports), which has the KMail
that will become KMail 2. KMail 1 from trunk is basically frozen for new
features at this point.

> Who cares for Akonadi at this very moment?

I do. Akonadi will solve many of the old standing KMail problems like flaky
online IMAP support, blocking GUI while filtering POP3 mails (yes, that bug has
even more votes than this bug here, just not as many noisy comments), various
storage-related crashes, index corruption problems, and many others.

> But for some reason everyone on the KMail team is stuck in the past and 
> insisting on QTextEdit instead of Webkit.

> Even if someone DID do this work, the idea of full HTML support in
> email will not get past the KMail "editorial board"

I really don't know where you get these ideas. I only said it is too much work,
which I have clarified above.
So again, for the last time: Nobody in the KMail team is against improved HTML
support. There is no secret conspiracy going on to keep HTML support out of
KMail.

I'd personally love to see full HTML support in KMail 2. Together with the
improved IMAP support, better searching/tagging and lots of other stuff that
Akonadi provides, it will make KMail rock!

Bah, I wanted to keep away from this bug report, but now I've found myself
commenting here again...

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.