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. _______________________________________________ Kdepim-bugs mailing list [email protected] https://mail.kde.org/mailman/listinfo/kdepim-bugs
