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 419805 - Find window obscures text
Find window obscures text
Status: RESOLVED FIXED
Product: gedit
Classification: Applications
Component: general
2.18.x
Other Linux
: Normal minor
: ---
Assigned To: Gedit maintainers
Gedit maintainers
Depends on:
Blocks:
 
 
Reported: 2007-03-18 17:25 UTC by Sebastien Bacher
Modified: 2010-09-09 21:17 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18


Attachments
Incremental Search has the same problem, just to a lesser extent (22.66 KB, image/png)
2007-03-19 20:46 UTC, Conrad Knauer
Details
quick mockup (144.09 KB, image/png)
2010-08-27 14:48 UTC, Andreas Nilsson
Details

Description Sebastien Bacher 2007-03-18 17:25:27 UTC
The bug has been opened on https://launchpad.net/bugs/93347

"Binary package hint: gedit

Just a wishlist bug; when looking for text, the Find window obscures the central portion of the screen, which can block the searched-for text. Contrast to how its done in Firefox (something along these lines would be great). This will probably have to be dealt with upstream, but I thought I'd mention it.

http://librarian.launchpad.net/6850837/gedit-search1.png
Where's the penguin?

Some screenshots...

http://librarian.launchpad.net/6850840/gedit-search2.png
You have to move the Find window away; this is like how it was in IE when I still used Windows (bad ;)

http://librarian.launchpad.net/6850843/firefox-search.png
Here's how they do it in Firefox; just spiffy! :)"
Comment 1 Steve Frécinaux 2007-03-18 19:28:00 UTC
I'm sure you'd love the incremental search (it's in the search menu as well).
Bottom bad didn't work well with the panes when we tried it.
Comment 2 Conrad Knauer 2007-03-19 20:46:29 UTC
Created attachment 84913 [details]
Incremental Search has the same problem, just to a lesser extent
Comment 3 Martin Ejdestig 2007-12-11 12:23:03 UTC
Incremental search does seem like an attempt to solve this bug but as pointed out in comment 2, it doesn't.

Also, I don't get why there is a need for two ways to search. One almost fixed and one completely broken...
Comment 4 Martin Ejdestig 2007-12-11 12:25:51 UTC
(In reply to comment #1)
> Bottom bad didn't work well with the panes when we tried it.

Maybe you could elaborate a bit, please?
Comment 5 Giulio Malventi 2009-08-08 10:37:36 UTC
Even automatically moving the dialog away from the selected text would be a solution. If I remember well, Kate does it.
Comment 6 Martin Ejdestig 2009-08-08 16:23:20 UTC
A moving dialog has some nasty usability issues.
Comment 7 Giulio Malventi 2009-08-08 16:42:42 UTC
For example? Personally I found it practical.
Comment 8 Martin Ejdestig 2009-08-08 16:47:43 UTC
You can't e.g. hit next twice in a row without moving the mouse pointer if the dialog happened to obscure the search result. Instead you will press somewhere in the main window.

Also, there is value in implementing the find functionality the same other
GNOME applications do it. Evince, Epiphany, Yelp, etc. all implement it with a
find bar at the bottom the way Firefox does it.

I'm sure there are a11n issues as well.
Comment 9 Giulio Malventi 2009-08-08 17:07:07 UTC
I totally agree about the firefox-like solution being better. My proposal was to be intended as a temporary quite simple fix while we wait for a better one. This bug has been already waiting for two and a half years, and even if it is not something critical, it is quite annoying.
Comment 10 Severo Raz 2009-11-02 22:58:26 UTC
I also think this is very important, but instead of embedding the search bar in the bottom, why not provide with a preference to select whether on the top or on the bottom? (I would personally select top)
Comment 11 zpletan 2010-03-13 17:24:11 UTC
This bug has been *ahem* bugging me for a while.  It is a big visual inconsistency that Gedit is the only app I use frequently that has a find dialog like this.  Even if I had no problems with a find dialog (which I do anyway), this visual inconsistency alone is completely... inconsistent (as well as relatively annoying).

On a technical coding note, it would seem as though it would be relatively simple to reuse code from evince, devhelp, or something similar.
Comment 12 jessevdk@gmail.com 2010-03-14 09:39:34 UTC
Just as a side note, we are planning to rework the find/replace in the upcoming development cycle.
Comment 13 Hylke Bons 2010-04-02 01:09:00 UTC
tell me if you need designs for this.
Comment 14 Andreas Nilsson 2010-08-27 14:48:49 UTC
Created attachment 168907 [details]
quick mockup
Comment 15 Andreas Nilsson 2010-08-27 15:52:23 UTC
I don't know if there is another bug open with this, but I was pointed out by nacho on IRC that he's working [1] on fixing the search dialog to be smaller and closer in design to what Chrome does (yup, the markers on the side too, but that is waiting for a GTK+ patch) [2].
This will also sport arrows for next and previous.

Paolo also mentioned that this would become the primary search method (and using ctrl+f) and that the old dialog would only remain for search and replace.

Regarding comment 2: It does indeed, but so does an entire line of chrome. If the search field can go as far to the right as possible, I think we can avoid covering the text in the majority of the text files people are dealing with (this introduces a very small visual hierarchy issue, but I think it's worth it in this case).

1. http://blogs.gnome.org/nacho/2010/08/10/gsoc-weekly-report-11/
2. http://jimstips.com/wp-content/uploads/images/stories/chrome/google-chrome-01-03.jpg
Comment 16 Ignacio Casal Quinteiro (nacho) 2010-09-08 11:33:07 UTC
The chrome like search dialog has landed in master. There are still some things to do like the arrows commented in the previous comment.
Comment 17 Ignacio Casal Quinteiro (nacho) 2010-09-09 21:17:35 UTC
Now that I added the arrow buttons I think we can mark this as fixed.