Created attachment 66718 [details] [review]
Proposed implementation

This patch basically adds a container for a search bar in the main window and implements a search bar widget that has interface similar to those of GeditSearchDialog. Since this is a limited-space widget, I dumped the "wrap around" combo in favour of binking a notification in the status bar, saying that the search has been continued from the top/bottom of the page.

Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

In particular, this design has been lengthy discussed and wasn't judged good at all, due to the bad interaction it has with the panes. There is also an incremental search thing binded with ctrl+k.

Feel free to come and discuss your ideas with us on #gedit if you feel the need to.

*** This bug has been marked as a duplicate of 153641 ***

See the comments at the top of #153641. The latest gedit still does not solve the real issue that the floating dialog obscures the search results. It's just a bit of a PITA for experienced hacks like me, but especially so to newbies to whom this strange behaviour has not yet been explained.

I don't know what was discussed in length or where, but what is this 'bad interaction it has with the panes' and can it not be addressed? What is an 'incremental search thing' bound to that nobody knows about? Is there any chance someone can post a link/summary of this discussion on this bug report, so the general public (i.e. non-gedit hackers list/IRC channel subscribers) know a little about the pros/cons that the gedit guys identified when they come across it. I'm sure there were perfectly good reasons, but they're not obvious from this report.

Sorry guys, IMHO, the current search dialog is *still* suboptimal and unusable, especially compared to the Evince/Firefox approach. Can this discussion/bug report be re-opened and settled in the open?

Ross: did you try the interactive search using ctrl+K?

http://advogato.org/person/pbor/diary.html?start=36 has some of the rationales (though it was just a short blog entry so it doesn't contain the whole thing)

The interaction with panes is that gedit has tabs on top and a bottom pane at the botton (e.g. if you use the external tools plugin or the python console plugin): wherever you put the search bar it looks ugly. There are other 'visual' issues with using a bar, like the use of vertical space (which in a text editing application is precious) or how to make the bar scale nicely when the window becomes smaller since 1024x768 is still a very common resolution. I am also personally not fond of firefoxesque searchbars because I find the bottom of the window to be the least intuitive place to pop up something and my eyes almost never look there.

The most important rationale however is that in an editor (as opposed to a read only application like firefox or evince) you really have two kind of search: one that finds as you type and one that doesn't, since find as you type doesn't work for search&replace. All the search bars in firefox, evince etc do find-as-you-type so a bar that does search&replace would be incosistent with them.

Thus we decided to have *two* search interfaces one quick find-as-you-type entry activated with ctrl+K and which doesn't obscure any text and the usual dialog for more complicated search operations[1] and for search and replace.
The dialog is also better suited to be extended with stuff like regex searches if we ever get to that.


At the moment I am pretty happy with the search UI situation, though if someone has ideas we are happy to hear them.


1: for instance I find the dialog handy when I search in different tabs since you can keep the dialog up and switch tab

> The interaction with panes is that gedit has tabs on top 
> and a bottom pane at the botton (e.g. if you use the external
> tools plugin or the python console plugin): wherever you put
> the search bar it looks ugly.

Point taken. Some find this ugly while maybe others would find a modal dialog way more ugly than a bottom bar that interferes with tabs they never see 'cause all they do is edit files, not poen side/bottom panes. This can be addressed - give people a choice on where to open search widget - in a modal dialog or in the ui. The design proposed in comment #2 can easily be adjusted for that, since it is a widget that absolutely resembles the API of the current search dialog. A GConf key can be introduces that controls whether to pack this search widget into a bottom bar or a modal window.

> There are other 'visual' issues with using a bar, like the use
> of vertical space (which in a text editing application is precious)

Isn't the space that gets obscured by the modal dialog more precious, especially at the moment when it has a highlighted search result? ;)

(In reply to comment #5)
> This can be addressed give people a choice on where to open search widget
> - in a modal dialog or in the ui.

Note that, as I said in bug #153641 comment #28, you can already do this by implementing your new search UI as a plugin. FWIW we already have two search UI (namely dialog/ctrl+f and incremental/ctrl+k) and I don't think it's worth adding a third one, since the devs are not particularly convinced by the search bar design. More, we'd like to avoid changing/adding ui for each release.

That's why the plugin system is great, it allows user to do nearly everything ;-)

Thanks for the details, Paolo. I get the picture now. Ctrl-K solves the problem, so I can see the arguments for a search bar aren't so strong any more :)

However, I think the 'Ctrl-K' should at least be mentioned in the manual next to the normal search, or in some kind of 'tip of the day' popup at startup or something. Otherwise some people will fumble along inefficiently forever using the full search dialog, without ever realising the 'incremental' search feature exists (unless the sstumble across this bug report or Paolo's blog).

yes, ctrl+K discoverability is an issue, though I don't have an easy answer to that. Obviously adding it to the manual is very much needed... In fact the whole manual needs love (see bug #343565). The rationale for not having a "Incremental Search" menu item is that it would be confusing: a user just wants to search for a word so we don't to make it pick 'blindly' *how* to search for it.