KListViewSearchLine

Scott Wheeler wheeler at kde.org
Mon Feb 16 13:18:06 GMT 2004


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

On Monday 16 February 2004 12:25, Frerich Raabe wrote:
> I think the idea is interesting but from looking at it, it seems like the
> brute force approach. How about an incremental counterpart to
> to KListViewSearchLine::updateSearch, which only searches among the 
> currently visible items instead of all of them?

I thought through most of this while designing the search stuff for JuK (which 
is a bit more complicated).  My original though had been to maintain a stack 
of items where after every key press you would add a set of items to be 
searched based on those that matched the previous string.

The problem there of course is that search strings are not always built left 
to right -- you can easily enter a character in the middle of the search 
string or just clear the query etc.  This isn't to say that some search 
optimization wouldn't be possible -- but it would need quite a few corner 
cases covered, but I didn't look into this too much because...

Painting is the bottle neck -- not the string matching.  Between 3.1 and 3.2 I 
did quite a bit of work on KListView to make this much better than it was 
before, but still given an "n" of the number of items in the list the 
constants for painting are much higher than they generally are for searching.

- -Scott

- -- 
Well this should cheer you up for sure.  You see I've got your old ID and 
you're all dressed up like The Cure.
- --Ben Folds Five, "Battle of Who Could Care Less"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFAMMMVQu0ByfY5QTkRAnZPAKCo32u1zoAHwv3yuXWdi84BxOnZsQCaAgkK
aUeM0BBxsQv9f3GYSCi+lI8=
=LZHb
-----END PGP SIGNATURE-----




More information about the kde-core-devel mailing list