[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: [patch] kword spell-checking
From:       till busch <buti () gmx ! at>
Date:       2002-03-25 21:36:40
[Download RAW message or body]

On Monday 25 March 2002 03:24, David Faure wrote:
> Well, yes, the first thing that strikes me is that nothing appears to be
> delayed anymore.........
> Can you explain the changes? This is so much of a rewrite that just reading
> the patch quickly doesn't really tell much about what it tries to address.
> What's the queue used for? Does it mean the spellchecking is actually
> delayed, so the loop over all framesets doesn't really check all framesets?
> [that would be a good thing ;)]

the only "delaying" currently is trough ispell being in a separate process. 
the idea is to send the whole text to ispell, and then wait for the replies, 
which naturally come "delayed".

maybe sending the whole text at once takes too much time. (especially for 
really large texts.)
the queue manages that ispell-replies can be correctly associated with queries 
to ispell. it would be needed even with the old approach, if you also want to 
check words as they are typed or modified.

>  - but the initial method did this by simply looking at "what's the next
> text object [frameset, in kword] to be checked". That way is more dynamic
> than a queue or a list, which means that when deleting a text object we
> don't need to look in the queue or list to see if it's still there
> (dangling pointer if it is!). We only need to check if it's the current
> object being checked, but that's all.

this is a real advantage of the initial method. so i guess i can set it up 
again. though the idea of checking multiple things at the same time seems 
necessary to me.

> What was missing in kspell that makes it necessary to have kospell?
> I'm not opposed to the idea, but since I fixed kspell as I thought needed,
> I'm wondering what's still missing there.

well. especially kspell didn't really work in non-blocking mode. it couldn't 
emit a done() for each check() -- at least not in the right order. not, if 
you sent multiple check()'s without waiting for the done() inbetween.
there are other (less striking) problems with the current kspell 
implementation. eg: checkWord() produces tons of errors and just breaks after 
some checks. also spell-as-you-type doesn't need dialogs, nor suggestions 
which i believe cause (at least some) overhead in kspell. (parsing the line, 
creating a QStringList [especially the way this is done -- without split()]).

> Design-wise I like the use of the paragraph visitor class there.... but I
> think the concepts of "what's the next object to check" (note the bool that
> was added to skip unchanged framesets etc.) and "wait a bit until checking
> the next object" should remain. Unless you found flaws with those concepts
> ? Please elaborate, we can't make a decision at this point without a
> comparison of the two methods ;)

ok, i like the idea, though i didn't like the implementation that "looped" 
(with QTimers) forever, i prefer calling something like checkDocument() once 
when loading, and then following any changes in the document. i think this is 
more logical then checking, checking, checking, checking..

so.. i can easily readd the QTimer concept for the initial check of the 
document, still i would very much prefer to follow modifications in the 
document directly. (which already works for typing - in my patch)

i'll send you a crypt()-ed password (to your personal address) for cvs-acces, 
but i still won't commit anything until everything is clear :)

nice greetings
- till

_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]