Add extended search interface working across tabs

[Amit Keret]

This is a feature request:

I'm using qpdfview mainly for academic work, and sometimes I'm searching for a topic of interest that can exists in multiple studies. This means I have to repeatedly switch between the open PDFs and search for the same phrase over and over again.

So I'm suggesting two improvements:
1. The last-searched phrase should be remembered for the next time a search box is opened. So after clicking Esc to close the search box, the next time it is opened it's not empty, but contains the last phrase searched. This is commonplace in many programs that offer text-search.
2. More importantly (and this would be the REAL improvement) - the ability to search in all open documents at once. This is something I've been using on Apple's Preview program, and it's a huge time-saver when reading multiple PDFs. So optimally, when searching for a phrase, I could iterate through all occurrences of this phrase in all documents. I believe this shouldn't be the default action, rather another mode of search ("Search...", "Search in all...").

Hope this can make it into development!

Thanks again for this software, it's improving tremendously with each release and I'm enjoying it very much.

[Benjamin Eltzner (b-eltzner)]

Hi Amit, if I am not mistaken, search results are currently transient and are lost on tab switch. This implies that it would probably be quite some work to reorganize the search function in the direction you suppose in your second point. (The first point seems quite reasonable and doable to me.) Therefore I suppose that such a change to the search function will not enter the upcoming release but will be deferred to a later release. In any case it would probably be sensible to discuss your feature requests on the mailing list.

[Amit Keret (amitkeret)]

Hi Benjamin,

I see your point, and yes, the search results disappear when switching tabs.
What I thought could be a possible implementation is that upon executing tab switch event, the program would check whether or not the search box is open and text appears in it. If true, it would automatically perform the search again on the new active document.
Does that make sense (or sounds user-friendly)?

btw - Will do re. mailing list in future. Was actually looking for a place to post feature requests, but couldn't find it...

[Adam Reichold (adamreichold)]

The extended search in all tabs at once was proposed on the mailing list by a developer who is possibly working on it right now, c.f. "https://lists.launchpad.net/qpdfview/msg00053.html" and follow-ups. But this will definitely have to wait for a later release.

Loosing the search term and cancelling searches on tab switch was done to ensure that the contents of the search text field always corresponds to the actual search present in the main view, i.e. to improve interface consistency. But I think this requirement is too strong for a tabbed interface and I would therefore remove it.

Hence, I just committed trunk revision 474 which does not clear the search text field explicitly or cancels a search upon switching tabs so that you can have several searches running at once independently. I urge everyone with time on their hands to test this since we are less than a week away from releasing version 0.3.2 (which however could be postponed by a week or so if necessary). (For slow searches, it possibly takes some time to display a correct progress after switching to a different tab. Not sure if there really is a need to do something about this.)

Finishing these smaller changes should probably be discussed here whereas the extended search functionality is really be discussed on the mailing list.

[Adam Reichold (adamreichold)]

As of now, the search progress should be updated correctly upon tab change.

[Adam Reichold (adamreichold)]

I know this is not really what is meant here, but at least, one can now (as of trunk revision 766) press shift and return to dispatch the search to all tabs. So even though there is no centralized interface to review all findings, one can at least save the time of starting the search in every tab manually.

[thinkpad (fellowsgarden)]

related feature request:

acroread uses "ctrl shift f" to open a dialog offering to search across pdf's in a specified directory.

that's pretty neat.
 (I'm aware that alternatives exist which ultimately accomplish more-or-less the same thing through the command-line...)

[Hermann San (hermann-san)]

An advanced search would be great.
In my opinion it should be something like the advanced search window in Acrobat Reader (see links below). It is a fantastic feature that I use on a daily basis. Especially the result list is very important to me because I can very quickly see where to click in the case there are many results for a search.

official Adobe doc + 2 screenshots of the Acrobat Reader advanced search.
http://help.adobe.com/en_US/acrobat/X/standard/using/WS047F7D61-E05E-4e82-98BA-F84B2E7A5974.w.html

http://blog.rockymountaintraining.com/wp-content/uploads/2010/03/2009_shots_0635.jpg
http://72.52.242.174/Adobe/answers.acrobatusers.com/UserFiles/Answers201403/answerImage91278-30024358.jpg

[Adam Reichold (adamreichold)]

Hello again,

please also consider that there more powerful and flexible solutions, e.g. using a general document indexer [1] and integrating it with qpdfview for example by using [2] which give at least the same speed for finding things and open up more general possibilities. And it is available now whereas I don't if and when this will be implemented.

Best regards, Adam.

[1] http://richfriedeman.com/2010/02/choosing-an-open-source-desktop-search-tool-part-3/

[2] https://bitbucket.org/medoc/recoll/wiki/QpdfviewHelperScript

[Hermann San (hermann-san)]

I´ll look into it. Thanks a lot for the hint.

[Amit Keret (amitkeret-i)]

I've used Recoll in the past, also for similar purposes (when doing academic research/work).
I found two downsides to it that made me prefer something like this feature request:

1. A desktop-based indexer indexes A LOT of stuff, and all these things come up in search results. I know that you can search only certain files, only certain folders... but this of course requires more configuration and hassle when all you want is to search through 3-5 documents and nothing else.

2. The UI is obviously completely separated from qpdfview. What I need most of all is a direct connection between the search I just performed and the documents. So, when searching, I can zip through all occurrences, and clicking each result will "jump" to that document... etc. That can't really be done when you're working with a completely separate application, but only when it's integrated to the document reader itself.

Having said all that... this is just my two cents. I realize it's not a small feature and of course in the meantime an working around the lack of it. Meanwhile, I'm enjoying the many updates to this application, it just keeps getting better :)

Thanks, Amit

[Adam Reichold (adamreichold)]

Hello again,

we still need to optimize the performance and the interaction details (which were optimized for one-off search until now), but basically if you use the latest daily builds, enable the extended search dock setting (restart required) and use the shift+return shortcut to search all open tabs, this should basically yield the necessary functionality. (However, we will not search the file system for now. This is strictly about the already open tabs for the time being.)

Best regards, Adam.

[Adam Reichold (adamreichold)]

After the implementation of moving surrounding text extraction into background threads and Razi's hard work of reviewing this into the proper shape for inclusion into trunk, this should now be pretty usable. (Of course still locked behin the "extended search dock" interface setting.)

From now on it's mostly about fixing resp. tuning the behaviour of the cancel search button in contrast to an additional close button for the extended search dock...

[Amit Keret (amitkeret-i)]

Adam and Razi,

I'm so happy to see this feature implemented!
The behavior is great, results appear fast and in an intuitive manner, I really like the way you coded this.

After some playing around, a few notes:
1. Looks like the setting should be done differently, currently it reads as though there's a new separate dock just for this. Since this is an enhancement to an already existing dock, I think it should say something like "Enable extended search (restart required)".
2. ...and once it's enabled, I believe the default behavior change to searching all open documents (meaning - no need for shift-enter to make it happen).
3. Only mouse clicks make the viewport jump between results, it's not possible at the moment to use this feature with the keyboard. I would suggest making this feature work with the Up/Down keys and/or the standard "Find next" shortcut.
4. Small bug: Since the results can be lengthy now, I've moved the search dock to the side (combined with the Outline dock). Now, pressing Ctrl+F doesn't focus the search dock - it just opens in the background as another tab in the dock. I have to use the mouse to click the tab, and only then it's focused on the search term. Positioning the dock BELOW the Outline dock is a good workaround for now, though.

Besides these, this implementation is EXACTLY what I meant for this to be!
Really tremendous work, job well done!

[Adam Reichold (adamreichold)]

Hello Amit,

Am 28.10.2014 um 06:46 schrieb Amit Keret:
> Adam and Razi,
>
> I'm so happy to see this feature implemented!
> The behavior is great, results appear fast and in an intuitive manner, I really like the way you coded this.
>
> After some playing around, a few notes:
> 1. Looks like the setting should be done differently, currently it reads as though there's a new separate dock just for this. Since this is an enhancement to an already existing dock, I think it should say something like "Enable extended search (restart required)".
> 2. ...and once it's enabled, I believe the default behavior change to searching all open documents (meaning - no need for shift-enter to make it happen).
> 3. Only mouse clicks make the viewport jump between results, it's not possible at the moment to use this feature with the keyboard. I would suggest making this feature work with the Up/Down keys and/or the standard "Find next" shortcut.
> 4. Small bug: Since the results can be lengthy now, I've moved the search dock to the side (combined with the Outline dock). Now, pressing Ctrl+F doesn't focus the search dock - it just opens in the background as another tab in the dock. I have to use the mouse to click the tab, and only then it's focused on the search term. Positioning the dock BELOW the Outline dock is a good workaround for now, though.

I made the search raise itself when search is activated and also
connected the activation signal of the tree view, so that you can
navigate the results using the arrow keys within the view and pressing
return.

I also changed the default search mode w.r.t. whether the extended dock
search dock is enabled. Note that we will probably make more adjustments
to the behavior of the user interface in any case, e.g. the cancel
button does not really work well with the extended search dock and we
will probably add a separate close button. So there is still some
optimization left to do anyway.

> Besides these, this implementation is EXACTLY what I meant for this to be!
> Really tremendous work, job well done!

Thank you for the praise.

Best regards, Adam.

[Hermann San (hermann-san)]

good work, many thanks.