Hello.
I am currently working on the search support and have a hard time choosing
an interface paradigm and dividing up responsibilities between the
involved objects, i.e. mainly the DocumentView and PageObject classes.
The current trunk revision has two button to search forwards and backwards
'step-by-step' which is simple and fast but only provides 'local' results.
This means that a 'highlight all' option and clearing the results of
previous searches might be burdensome to implement. On the other hand, if
you currently just press return in the search field, a background search
will go through the whole document and cache the results. This is quite
lengthy and would shift the responsibility of drawing the highlights from
PageObject to DocumentView. But it would allow easier handling of all the
results combined.
A background search also yields synchronization problems: How should the
'find next' button behave if the search is just not finished yet which
could mean that existing results are not yet available. Should it just
block? (Maybe this does not matter if I make the background search start
at the currently displayed page?) Under which conditions should the
background search start? I was thinking of starting a timer after the
search text changes and beginning to search if the text did actually
change from the last search and was not modified for like one second or
something.
What are your ideas for a sensible search interface? Especially keeping
the fact that search seems to be quite a slow operation in mind.
Best regards, Adam.
P.S.: Any ideas what we should add to/change on the outline and thumbnails
views?
--
Mailing list: https://launchpad.net/~qpdfview
Post to : [email protected]
Unsubscribe : https://launchpad.net/~qpdfview
More help : https://help.launchpad.net/ListHelp
