qpdfview team mailing list archive

["Adam Reichold" <adamreichold@xxxxxxxxxxx>]

Hello again.

Am 22.03.2012, 23:10 Uhr, schrieb bdjnk <bdjnks@xxxxxxxxx>:

> Brilliant work! That was some fast effective refactoring. So aside from  
> pure amazement at how awesome everything worked, here are the issues I  
> ran into:

I'm not that sure that "fast" is appropriate, but it's nice that you like  
it.

> Entering a new search term and pressing next results in the previous  
> search term being sought. This may be intentional, but if doesn't feel  
> like rule of least surprise to me.

It is not intentional. If the search is redone only when pressing return,  
the document itself doesn't "know" about the changed content of the search  
field. Therefore it is still iterating the old results.

> There is no way (that I've yet found) to un-highlight the search  
> results. Whatever is highlighted remains highlighted until a new search  
> is initiated.

I just hadn't though of that. :-( But actually, after thinking of it,  
things simplified a bit again. :-) This should now happen when a the  
search bar is closed or the tab is changed. (The point was to really  
enforce the separation of searches being initiated and canceled in  
DocumentModel by MainWindow and a change of the results being signalled to  
DocumentView (and PageObject) by DocumentModel. I should probably draw a  
nifty diagram some day...)

> There are also some points where the previous search term becomes lost  
> if it is deleted from the search box. For example, when a search is  
> made, then the search term is erased, then the document is rotated,  
> zoomed, or the view type is switched. In that case the search will be  
> nullified, while not erasing the search term will result in the search  
> remaining active.

This is again the "problem" of manual control over the start of a new  
search and should be gone. When the search term is edited, the current  
search is invalidated and a new one started. The same when the search bar  
is closed or the tab is changed. This also brings back the notorious  
search timer. Again you can burn your CPU if you type really slowing, but  
it should not hand the program. (And 1 second should be enough to type  
more than two letters. Or should this be increased? Thinking of some older  
people...) You can also force the timeout by pressing return.

> There may be more, but that is as much as I have time to test right now.

Any help and time spent is very much appreciated. It is really getting  
hard to find all the corner cases as the complexity of the UI increases.  
Especially the tabs seem to make things difficult. :-) What would probably  
help at this point is testing of the things besides search. I didn't  
really change any functionality, but with all the changes made. Who knows  
malicious error I made that will result in "format C:" being executed.  
Wait, that was another time...

Best regards, Adam.

> On 03/22/2012 11:50 AM, Adam Reichold wrote:
> > Hello.
> >
> > Because of the problems encountered when implementing the requested  
> > additions to the search feature, I started rather extensive refactoring  
> > to improve the structure of the code base. With regards to  
> > functionality this should be the same as trunk revision 81 but the code  
> > changed considerably and is hopefully much easier to understand. (Well  
> > the problems with search results being discarded after a change of  
> > display mode should be gone.)
> >
> > If this did not introduce serious regressions, I will start improving  
> > the source code documentation. But to find out, this needs to be  
> > tested. Because the reshuffling of code is so extensive, I would ask  
> > you to test all the functionality again if you have the time. It is  
> > probably not necessary to open bug reports for every regression  
> > introduced, just post to this mailing list thread. Thank you for your  
> > help.
> >
> > Best regards, Adam.
> >
> > P.S.: One nice side-effect of this is that I also have a litte crazy  
> > branch where poppler is replaced by fitz, the PDF rendering library  
> > used by mupdf which seems considerably more lightweight and has proper  
> > support for multi-threading. (And seems to have even worse  
> > documentation that poppler. :-()