Progress bars vs. lazy querying about dact

[jelmervdl]

I think we can replace most of the progress bars with simple indicators like e.g. Spotlight uses on OS X. It just indicates more is to come, but you can already use the results that are found. Most of the queries,if not all, are done async and should not block the ui thread. (They do now sometimes, but that's a bug)

I think we do need to keep some sort of animated progress bar or indicator. When there are only a few results to be found, a counter would not indicate whether or not we are still searching.

Afaik the only place a progress bar in a window is used is on opening a file, preventing the user of doing anything (well, except cancel opening the file) Maybe it is worth it to make this also non-blocking, load the list of files in the background using the same meganism we already use to load query results. This would allow people who just want a subset of the treebank to start entering their filter query without having to wait.

[larsmans]

I can add a size() method to EntryIterator that throws an exception if the size cannot be determined. Then we can display a progress bar or a counter/animation conditionally.

[jelmervdl]

For now that would be a good solution.

[larsmans]

Skip this idea: it's too hard to keep the iterators in a consistent state and they quickly become overweight. The UI should simply call size() on a CorpusReader and not expect to know the size of a queryset before the query is run to completion.

[danieldk]

I think with some exceptions (e.g. the statistics window), we should switch to Qt's model/view architecture. Views lazily fetch results (e.g. when the user scrolls).