KTextEditor

[David Faure]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 05 October 2002 12:44, Don Sanders wrote:
> On Thursday 03 October 2002 18:10, David Faure wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Thursday 03 October 2002 07:56, Don Sanders wrote:
> > > The first feature, incremental spell checking is the feature I
> > > would most like to see. Was I correct in recalling that you
> > > intend to work on that feature? If so then (how) would we be able
> > > to reuse that work in KMail?
> >
> > There are two solutions.
> > * Using KWord (or rather a new libkotext-derived component, we
> > don't need frames and footnotes and all that stuff ;))
> > * Moving KoBgSpellCheck to kdelibs and using it in KMail.
> 
> I'm trying to work out the pro and cons for each approach.
> 
> Using KWord or a libkotext-derived component would have the con that 
> KMail would become dependent on the koffice package right?

Not necessarily. You could embed a component (dlopened), that provides
this functionality.

> And the pro would be that it actually works and bg spell checking 
> would work 'out of the box'. Oh and html exporting is available too.
> 
> 
> Moving KoBgSpellCheck has the con that somebody has to do the work to 
> get it working with KMail. It seems that currently KoBgSpellCheck 
> works only with koTextParag and koTextObject, so someone would have 
> to try to generalize it to work with either a QTextEdit or KRichText 
> widget is that correct?

Yes, it would have to be "generalized". Which would be a good thing to do
for e.g. kate - I think I heard developers who wanted such a thing.

[...]

> I'm shying away from using the KTextEditor interface because I think 
> it's going to require too much effort to get koBgSpellCheck to work 
> with the KTextEditor interface, and because that interface doesn't 
> support rich text.

I don't see problems here.
- - The background spellchecking could be entirely up to the component,
nothing to add in the interface. The component might provide a toggle action
for activating/deactivating the feature, and a "configure" action to choose
the language, but the whole feature itself is entirely in the hands of the
component (e.g. KWordPart).
- - As stated before, the only "rich text"-related method needed in the interface
is something like "save to HTML". What else does KMail need?
All the stuff like bold/italic/font/fontsize etc. are actions provided by the component
itself, no need to change the interface for those... I'm wondering if you understand
the idea behind KParts ;-)

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
Get the latest KOffice - http://download.kde.org/stable/koffice-1.2/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9oT0772KcVAmwbhARApWlAJ9q94HDjND+XX0teaPbACV7k3+o7gCcDJE4
o8f7cT6X5vOZOBxFVx64sMA=
=JMTr
-----END PGP SIGNATURE-----