KTextEditor

[Don Sanders]

On Monday 07 October 2002 17:52, David Faure wrote:
> -----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.

But that's still a runtime dependency. I'm concerned that requiring 
people to install koffice in order to use KMail is too big a 
dependency. Not so much for the typical end user but rather for 
contributors who build from cvs.

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

Perhaps I didn't explain myself clearly, this is not a KParts issue. 
It's not what KMail needs it's what interface a generalized 
koBgSpellCheck needs.

 I checked out koffice looked at koBgSpellCheck.cc and began working 
out what would have to be done to generalize koBgSpellCheck to work 
with some interface other than the koText inteface.

My immediate observation was that koBgSpellCheck methods make 
extensive use of KoTextParag, I guessed that this was similar to 
QRichText parag, and made the inference that generalizing 
koBgSpellCheck to a paragraph based QRichText based text widget would 
be a relatively simple task compared to generalizing koBgSpellCheck 
to work with the KTextEditor interface (I guess the KTextEditor 
interface doesn't have the concept of paragraphs).

I am also assuming that if koBgSpellCheck is moved into kdelibs then 
it is desirable for KOffice to use the koBgSpellCheck in kdelibs, 
right? If so then koText will have to support the interface required 
by koBgSpellCheck in kdelibs. So if koBgSpellCheck in kdelibs 
required the KTextEditor interface then koText would have to support 
the KTextEditor interface (in order to use koBgSpellCheck in 
kdelibs). I think such a task could be reasonably demanding and 
require ongoing maintenance so I wouldn't want (anyone) to do it 
unless there are real benefits.

Don.