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

[Zack Rusin]

On Tuesday 21 January 2003 23:46, Don Sanders wrote:
> > 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.

Well, this is not going to happen because KEdit is deprecated in itself 
and KTextEditor took over. I was thinking about the way I want to do it 
in the new composer and here's a suggestion:
- have our own editor factory which would yield the following two 
widgets:
   * our own native editor, (most probably QTextEdit derivative),
   * KTextEditor component, thanks to which 
kvim/kate/hopefully-finally-emacs could be used,

I'm rather reluctant to go with the KTextEditor only solution because 
quite frankly I still don't see any simple KTextEditor component 
suitable for mail composing. So for 3.2 I'd prefer to have a composer 
where the default editor is our own QTextEdit derived widget and 
KTextEditor is optional and then maybe change it the other way round 
after 3.2. 

I mean I like KEdit, because at this point KTextEditor suck for anything 
else than coding. The idea behind KTextEditor is great but we're 
missing some simple editor component. 
If someone took KRichTextEdit and ported it to KTextEditor, that'd be 
the best. The only other complains we can have about KTextEditor are:
- lack of spell checking interface which from what I know should be 
there for 3.2,
- lack of an interface along the lines of QSyntaxHighlighter (and no, 
HighlightingInterface is not even close to QSyntaxHighlighter).

Zack

-- 
"The Internet is like a gateway to the net" - Bob Dole