Version: (using KDE KDE 3.4.0) Installed from: Gentoo Packages The quicksearch function is blocking the UI. For large PDFs this blocking can easily last a few minutes. Here's an example. I opened the "C++ GUI Programming with Qt3" book (phptr.com/content/images/0131240722/downloads/blanchette_book.pdf) and just typed "Linux". The result: kpdf was blocked for 47 seconds (on an Athlon 700). Subsequent searches are blazingly fast. It seems that kpdf synchronously converts the pdf to text. Hopefully this can be fixed. Apart from this unfortunate bug, it's the best PDF viewer I've ever used. Congratulations for an excellent (and much improved) 3.4 release!!
True, we have to try to make the search threaded.
Gilles: what are the solutions that you will like to fix that thing? I mean.. how to stop a search if it wasn't synchronous? or stuff like that.. please tell us about simple solutions :-)
On Saturday 02 April 2005 09:49, Enrico Ros wrote: > Gilles: what are the solutions that you will like to fix that > thing? I mean.. how to stop a search if it wasn't synchronous? or stuff > like that.. please tell us about simple solutions :-) I think you're asking the wrong one... I haven't got much programming experience and none at all concerning KDE. Creating a search thread or process that notifies the UI when it's done would be a first step. Meanwhile the UI could at least inform the user that searching will take some time. It would of course be better if the search results would appear as soon as they are found, i.e. you'd have a continuously growing list of pages and occurrences. Hey, I'm not (yet) a programmer. ;-)
I was just going to report this bug and found this duplicate report. Here's is how I think it could be solved: * When the user starts to type in the search box, thread T is started that converts the pdf to text (or whatever it is doing when it pauses). * Some sort of notification should appear altering the user that the "Document text is being searched...", such as using the current method that explains how to use the set mouse mode. The notification should be non-blocking (i.e. not a dialog box) as this interrupts the user. * When the user has entered 3 characters into the search box, thread T should be passed the information of what should be searched for. The page filter should then update immediately with any partial results. For example, if T has made it half way thru indexing the document, it should show the pages from that half that contain the search word. There will also need to be some kind of message somewhere so the user knows searching is still going on (e.g. "Document is being seach. Some matches have already been found."). * Thread T should then continue until it is finished, updating the found pages as it goes. All further searches will presumable appear instantly. I think the important points are the user should be altered to what is happening (i.e. that they are waiting for search results and they will appear soon), they should be given results as they are found and they should be allowed to navigate the document in the mean time. For example, they can read a few random pages as they wait for searching to finish. As the indexing can take about a minute for large documents, you need to let them to something while they are waiting. The index could even be done when you first open kpdf, but there is obviously a speed/time trade-off here if you don't intend to search it. Perhaps indexes could be stored in some kind of cache so they only ever have to be generated once. Fantastic application by the way, the best pdf viewer I've ever used. ;-)
*** Bug 151128 has been marked as a duplicate of this bug. ***
Closing this bug. kpdf is no longer under development and the okular team has already implemented it. If you still have problems with this feature when using okular please open a separate bug.