I did a slew of changes in trunk related to all listviews, except PersonView.
With last commit all should be working fine. If people try it and have
issues, don't hesitate to write back.
* Always one column is sorted
* Inverting the column order (ascending <--> descending) is very fast
(no sorting in mem anymore, just a key switch)
* doing a filter search or topbar search does not recreate possible
keys anymore, so should be faster (filter can be slow though)
* insert/delete are done in memory on the model, so should be very
fast (no rebuild after it)
This is tested on a 9400 row view and works fine on my box. Note that
due the sorting all sort keys must be obtained from database before
list can be build, so faster than iterating over the database to
obtain these keys is not possible.
Things that still can be improved:
* sorting on a type (eg event type) is much slower than sort on eg
placename. This is due to the overhead of obtaining the type from
database, then converting to a string representation. This conversion
should be investigated, and perhaps a cache on the default types added
to speed things up?
Bugs I know of:
* if you change a row and change the key that is sorted in the
view, the view is not updated to reflect new correct sort position.
This was present already in 3.1. Not too difficult to fix.
PS: Things that might be interesting:
*It might be interesting to build a performant view that matches
exactly the database hash table of the database, so sorting of course.
I know of one implementation of treeview that works directly on a
bsddb, but in that case the tables are btree tables. We have hash
tables for our primary objects. This is workable too however:
--> number of objects: one call
--> database has a set_location and a next method to immediately find
a handle. So the index2handle map could be created on the fly as
needed mimicking the hash table.
* I intend to change PeopleView likewise.