As-you-type spell checking and color quoting implemented in the composer

[Don Sanders]

On Wednesday 22 January 2003 04:01, Marc Mutz wrote:
> On Tuesday 21 January 2003 15:10, Don Sanders wrote:
> > The original code is by Trolltech AS and I ported it to KMail and
> > KSpell. It's based on the new QSyntaxHighlighter class.
>
> What are the changes? Can't they be contributed back into
> QSyntaxHighlighter? I mean, you're sitting at the source...

I didn't make any changes to QSyntaxHighlighter, the color quoting and 
spell checking are examples of using QSyntaxHighlighter. (Reuse is 
through inheritance rather than aggregation).

Another nice use might be checking for doubled up up words.

> The other question is: How does that relate to the planned rich
> text editing (composing basic t/enriched and t/html) in KMail?

The KMail composer currently derives from QTextEdit. This class 
supports everything we need for t/enriched and t/html mails.

The KMail composer also inherits from QMultiLineEdit which is not nice 
architecturally as this later class is deprecated. KMail uses KEdit 
which derives from QMultiLineEdit, it would nice to simply port KEdit 
to KTextEdit, (I hope this is easy to do). And then maybe call this 
new class KSpellEdit, I guess you can't change the inheritance 
hierarchy of KEdit as that would be binary incompatible.

This would yield the following benefits:

KSpellEdit can be used everywhere KEdit used to be, (KMail, KEdit, 
etc) this would require minimal or no changes to these applications 
source code.

KEdit which is deprecated due to its inheritance from the deprecated 
QMultiLineEdit is no longer used anywhere in the standard KDE 
packages.

KDE (libs) doesn't lose the only editing widget with support for spell 
checking. (This is correct right KEdit which is deprecated is the 
only class in kdelibs that supports spell checking, right?)

KTextEdit (which is meant to replace the deprecated KEdit class) can 
actually do so as KSpellEdit will derive from KTextEdit.

> Is
> there a way to coexist for the two? Won't that be confusing to the
> user ("What will be sent how? Is every mail I compose now
> automatically rich text b/c the quoted text is coloured?")?

It might not be confusing at all, I would like to try it before 
deciding. But if having t/enriched, t/html and color quoting and 
as-you-type spell checking on all together is confusing then we can 
just limit the user to non confusing options, or give the user the 
option of turning off/on individual highlighting methods.

I don't think as-you-type spell checking and color quoting support is 
confusing. It should be pretty obvious that KMail won't send emails 
with all misspelt words highlighted in red (or whatever color), and I 
think it's pretty obvious color quoting information is also part of 
the view not the document, since it's in sync and shares this 
property with the mail reader window.

Don.