KFind patch for incremental searching

[Arend van Beelen jr.]

On Monday 07 June 2004 11:18, David Faure wrote:
[...]
> I see.
> I hope the applications will free the KFind object (or at least clear its
> cache) when stopping the incr. search though; it sounds quite expensive to
> have a full copy of the document's text in memory (think of a 150-pages
> kword document).
Well, freeing is kind of troublesome as you never know when the search 
finished because the user can always issue a Find Next. KHTML will delete and 
reallocate the entire KFind object when a new search starts though.
But I don't know how KOffice stores its documents in memory, but given the 
fact QString uses shallow copies, the memory consumption should stay at a 
minimum and the cache will only have real copies of the data blocks if the 
set data blocks are destroyed in the calling application (like KHTML does).

> BTW the class docu should probably be extended to explain 
> how to use incr. search with KFind: should one call setData() for the whole
> document right away?
Yeah, I think I will need to add some more clarification there, right now the 
incremental search works quite transparently but that will change if using 
ID's...

> > > Hmm, I see that the main point might be performance (we'd lose the
> > > QDict). Maybe KFind can provide some help there but still leave full
> > > control to the application (for iterating over the paragraphs, and
> > > possibly invalidating some data). Hmm. Or maybe all we need compared to
> > > the current patch is a way to invalidate a given entry in the 'texts'
> > > vector (and handle its associated matches somehow) - or even clear the
> > > whole texts vector if too much changed (e.g. one or more paragraphs
> > > were
> > > added/removed).
> >
> > Yeah, and that could probably be achieved by using ID's as mentioned
> > above.
>
> Agreed.
The only thing I'm a bit worried about is how to handle insertion of data 
blocks (paragraphs) at random points in the cache. Does KOffice increment all 
following paragraph ID's if one paragraph is inserted or are paragraph ID's 
non-lineair? In the former case insertion could become a rather expensive 
operation, in the latter case it would probably require both a QValueVector 
and a QPtrList to keep track of both the ID's and the order in which they are 
in the document. The latter case would also require a more complex insertion 
function in which you can specify at which position you want to insert the 
block with the new ID. Personally I would prefer the first option (lineair 
ID's). A single insertion could then result in a number of setData's and the 
burden to keep track of those is placed on the calling application, but the 
KFind class itself is saved from a lot of extra complexity.

> > > > +    // KDE4: move to KFind
> > > >     enum Options
> > >
> > > That's arguable. The idea is that KFindDialog can be used without
> > > KFind... OTOH I guess that if such apps have to include kfind.h just
> > > for the enum it's not a big deal either, and for apps that do use
> > > KFind+KFindDialog it would indeed look more consistent.
> >
> > It's indeed arguable :) But now we have an option in KFindDialog which
> > has nothing to do with the dialog. And the only dependancy KFind has on
> > KFindDialog are the options, so the idea of being able to use KFindDialog
> > without KFind would be changed to being able to use KFind without
> > KFindDialog, which sounds more logical to me.
>
> So does the new option have to be in setOptions()? Why not a separate
> bool setting in KFind? After all the KFindDialog options are those coming
> from the dialog :) 
No, KFindDialog options can come from the dialog, but don't have to.

-- 
Arend van Beelen jr.
http://www.liacs.nl/~dvbeelen

So if you want my address, it's number one at the end of the bar.
-- Marillion