As-you-type spell checking and color quoting implemented in the composer
sanders at kde.org
Wed Jan 22 04:46:15 GMT 2003
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
KEdit which is deprecated due to its inheritance from the deprecated
QMultiLineEdit is no longer used anywhere in the standard KDE
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.
> 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.
More information about the kde-core-devel