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

[Don Sanders]

On Wednesday 22 January 2003 10:52, Zack Rusin wrote:
> 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.

IIRC KEdit is deprecated because it relies on QMultiLineEdit which is 
deprecated. If KEdit can be ported to (Q/K)TextEdit then that ported 
class would not be deprecated. 

Instead of thinking about it as a KEdit port another alternative would 
be thinking about it as using KSpell to add spell checking 
capabilities to KTextEdit.

I should point out that I don't have much desire to do this work 
myself. My immediate goal was to add spell checking and color quoting 
to the KMail composer and I'm satisfied with the qsyntaxhighlighter 
solution, so I would like to polish any rough edges on this solution 
and then move onto my remaining high priority tasks, (subject 
threading, client side imap filtering, full text index, imap 
searching, etc)

BTW I wouldn't say that KTextEditor took over, existing apps haven't 
been ported to it, I guess partly because it doesn't support spell 
checking, yet. (At least I wouldn't consider it a suitable 
replacement for the KMail composer yet because of this reason).

> 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.

Sure, agreed, (after reminding myself that KTextEdit != KTextEditor)

> 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).

I'm ok with supporting multiple editors, I feel bad about not replying 
to the guy on kdepim who posted the port KMComposeWin to use the vim 
part patch.

Don.