KTextEditor

[David Faure]

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

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

No, it's not a strict runtime dependency, if you have other implementations of KTextEditor,
like kate. The idea would be:
* If you want plain text editing in KMail (like right now), you only need kdebase
(or even kdelibs if there's a ktexteditor implementation there, I don't know the current status).
* If you want richtext editing in KMail, then you need koffice.
It's a "weak" dependency. KMail runs without it, but if you want the extra feature,
then you need koffice.
Ok, now the choice is yours, but I wanted to make this clear.

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

That's the 2nd solution, yes. Don't mix them ;)

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

Problem is, you can't use QTextParag. It's a private Qt class.
[I don't know how one can make anything out of QTextEdit, but that's
probably simply because I'm too used to its internals (and I don't
know the "public API" way of doing things with it).]
So if we want to have (keep?) a text-editor component that implements
KTextEditor and that is based on QRichText, then I think we can't have
a KTextEditor-centered bg-spell-check implementation, unless I miss
something.
So, in order to avoid having to go for the "lowest common denominator",
my idea would be to let individual text-editor components provide
background-spell-checking. Which still means moving some generalized
version of koBgSpellCheck to kdelibs, but as an independent class
that Kate (and KOffice) would use directly.
This also makes it possible to use it in non-text-editors apps, like
khtml form fields, kspread cells, etc. Binding kobgspellcheck to KTextEditor
prevents this from happening.
Hmm, ok, khtml form fields is a bad example, we could use KTextEditor there.
But surely not for each kspread cell.

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

One step at a time. If you go for this solution (generalized bg-spell-checking
feature in kdelibs on top of the KTextEdit interface), then this is independent
from KOffice. Whether we switch to that code in KOffice or not (and whether
we implement the KTextEditor interface there), has no bearing on KMail,
in that solution. We can keep our own "copy" (although quite different from
the one in kdelibs, I suspect) until the need to "merge" arises.
(Yes I hate code duplication, but it shouldn't prevent us to move on, when getting
rid of it is too much work).

Anyway, as I stated above, I think it would be better to have "background spell
checking" functionality independently from KTextEditor, so this problem
doesn't happen.

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

iD8DBQE9oWB472KcVAmwbhARAjVeAKCNc1dFnKvEHmMJC1YD/egPmREXFwCeJZxe
y7yuxxBwDJXtYjLGvpOKm5o=
=cHLX
-----END PGP SIGNATURE-----