After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 311838 - Seach backward requires several clicks to find word
Seach backward requires several clicks to find word
Status: RESOLVED FIXED
Product: evince
Classification: Core
Component: general
git master
Other Linux
: High normal
: ---
Assigned To: Evince Maintainers
Evince Maintainers
Depends on:
Blocks: 312019
 
 
Reported: 2005-07-28 09:45 UTC by Nickolay V. Shmyrev
Modified: 2005-08-12 05:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Make "find previous" work sensibly (1.08 KB, patch)
2005-07-31 17:56 UTC, Colin Slater
needs-work Details | Review
patch #2 (2.73 KB, patch)
2005-08-03 17:02 UTC, Colin Slater
none Details | Review

Description Nickolay V. Shmyrev 2005-07-28 09:45:38 UTC
Try to search for a word in multipage document. For example, if the word
appeared in the page 5 and in the page 1. First you find occurence of word on
page 1, then on page 5. But then if you'll try to search backward, you'll be
managed to press backward button 4 times.

That is because backward button internally decrease current search page and to
find occurence on page 1 you should decrease current search page 4 times.
Comment 1 Colin Slater 2005-07-31 17:56:16 UTC
Created attachment 50024 [details] [review]
Make "find previous" work sensibly

Attached patch makes "Find previous" work like one would expect.
Comment 2 Nickolay V. Shmyrev 2005-08-01 00:30:11 UTC
Hi Colin

Thanks for nice patch, unfortunately it need some work. Try for searching
non-existent word in document, then your patch will lock in infinite loop.
Probably you need some check for loop. 

But generally as you can see your solution is a bit out of ideology of find. To
my opinion, search process should be reworked to completely avoid possibility of
such bugs, but it should be consistent. For example, I am thinking about
dropping of find page + find result pointer and usage of something more natural
for searching. But that is only my thoughts not completed in implementation idea.
Comment 3 Colin Slater 2005-08-03 17:02:51 UTC
Created attachment 50185 [details] [review]
patch #2

You're right. The other patch didn't make sense. I went back and read more of
the code, and came up with something more logical. The behavior when searching
backwards for a non-existent word is still a slight problem. It seems to me
that there should be a clear way to report to the user "search term not found,"
but that probably requires more significant changes to the find mechanism.
Comment 4 Nickolay V. Shmyrev 2005-08-12 05:42:57 UTC
Sorry for delay, this problem should be fixed now, I've updated this patch and
committed it. The minor problems with it was:

1. It's better to use enums than defines, since it allow possibility of
type-checking with compiler and makes code more safer (Imaginary possibility, but
still)

2. There should be also one additional line:@@ -2765,7 +2772,7 @@
jump_to_find_result (EvView *view)

        n_results = ev_document_find_get_n_results (find, page);

-       if (n_results > view->find_result) {
+       if (n_results > 0  && view->find_result < n_results) {
                ev_document_find_get_result
                        (find, page, view->find_result, &rect);

Otherwise, when you will search for nonexistent word backward it will decrease
one page on every click.

So thanks a lot. I've filled some additional bugs about searching, most are
easy-fix also. Probably you'll enjoy with fixing them, since you already familar
with this area.