GNOME Bugzilla – Bug 153641
proposal - rework gedit search ui
Last modified: 2010-06-08 05:50:38 UTC
It has come clear that the current search interface (a floating dialog) is suboptimal for a number of reasons (among others: the dialog hides the results and keyboard navigation including the ESC button debate). Among other see bug #115070 This bug is meant for discussion of an improved search in gedit, both from a UI standpoint and with regard to implementation. Bryan Clark recently discussed (http://www.gnome.org/~clarkbw/blog/finding_a_good_find) a possible new design for the search interface, which mainly revolves about printing the search results in the output window. While such design brings some interesting points and seems to work great for apps like gconf-editor, I fear that it isn't adequate in a text editor like gedit, mainly beacuse it does not deal with search and replace. Another approach (not new in fact, see for example nedit) has been recently adopted by firefox: instead of a popup dialog a search bar is created at the bottom of the page. Discussing with Paolo Maggi, we decided that something resembling the firefox approach would fit better our needs, so here is a first mockup proposal to get the discussion going. Note that there are still issues, in particular: 1) top or bottom? Chose if the search bar should be positioned at the top or at the bottom. Pro anc cons: at the top the tabs bar would end up between the search bar and the text area, while at the bottom the search bar could conflict with with the output window. For what is worth firefox positions its search bar at the bottom. 2) Layout With only "find" (like in firefox) the layout of the search bar is pretty easily done, but things get more difficult when also the replace action must be included in the UI. The widgets which must fit in the layout are the following: - a Find entry (a combobox actually, to hold previos searches) with the associated "Search:" label - a similar Replace entry - an output label to hold messages like ("No matches found", "restarting from the top", etc) since we dont want popup dialogs. - 4 buttons: Find Next, Find Previous, Replace All, Replace. - a close button - two toggle buttons: Match Case, Match Entire Word Note in particular that beside the usual general pleasentness and HIG compliance the layout must deal with the following requirements: - take as little as possible vertical space away from the text area - work nicely if there is not much horizontal space, for instance when the window is not maximixed a quick mockup of a proposed layout is attached (really *quick*, bear the ugliness and mixed translations etc) Some possible variations that come to my mind are: - have the Next and Prev button beside the Find entry and the Replace and Replace All button beside the Replace Entry - use icons instead of labels for the toggle buttons - put the Replace Entry beside the Find Entry 3) Keyboard navigation The search bar should be easy to use with only the keyboard. In a particular a nice shortcut to hide the search bar should be decided.
Created attachment 31903 [details] first ugly mockup
Created attachment 31906 [details] firefox search bar, for those who do not have it handy
discussed this a bit on irc with dobey and dowem: dowem: pretty much liked the proposal and in fact did similar mockups a couple of weeks ago dobey: didn't like the proposal and afaict didn't like clarkbw proposal either, he'd prefer to keep the current dialog approach amybe making it close once the first result is found. I considered that approach too if we decide to keep the dialog, at least the esc and dialog-cover-result problem go away. OTOH we would lose the ability to cycle fast to through the results (ok, for keyboard using people there is ctrl+g). Even if he didn't like the search bar idea, he provided the following input: - remove the output label, use the status bar instead - maybe use the bar only for find, but not for find&replace I agree that the label can go, though I'm a bit worried that some of the messages show up only in the statusbar when they used to be way more visible, in particular the "No matches found" message which used to popup an info dialog. Instead I don't like the idea of using the interface only for find and keep the dialog for replace.
Created attachment 31923 [details] A mockup This is a mockup I have designed with glade. I think we can eventually chande "Find Next" with "Next" and "Find Previous" with "Previous" to reduce the width.
Created attachment 31926 [details] A second mockup Here you can see a second mockup. I think that the width of both the "Find" and "the Replace" bar is small enough. I have removed the close button and I have changed the "Find" and "Replace" buttons in the main toolbar to be toggle buttons. If the "Find" button is pressed, the find bar is displayed. If the "Replace" button is pressed, the "replace bar" replaces the "find bar"
Created attachment 31927 [details] The glade file used for the previous mockup In the above mockup there are two toggle buttons just after the text fields. We need icons for them. The first one is to enable/disable case matching, the second one is for "Match entire word only".
If we agree on implementing the solution I have proposed we need the following icons: - Match case - Match entire words only - Replace All It would be cool to have the followig icons too: - Find Next - Find Previous Note that we need to add some space just before the "Find" label. If we want to show "status messages and icons" like in Firefox we will need also the following icons: - Reached end (top) of page, continued from top (bottom) - Phrase not found
While turning the find on the toolbar in a togglebutton reflecting if the search-bar is visible is nice idea, I'm not too fond of not having a close button to hide the search-bar: for example in a distant future it would be nice to have a customizable toolbar (like epiphany) so the find and replace toggle can be not there.
Well, I don't think gedit will ever have a customizable toolbar... but who knows :-) BTW, you are probably right about the problems of not having a close button to hide the search bar could cause. For example... should we have "View->Search Bar" and "View->Replace Bar" menu items? What about keynav? Will Ctrl+F be associated to "Search->Find" or to "View->Search Bar"? A possible solution could be: - Adding close button - Do not add the "View->Search/Replace Bar" - Do not change the current menus. We could actually kill the Search menu and moving it to Edit. I will try to produce another mockup.
Created attachment 31947 [details] A new mockup with close button
Created attachment 31948 [details] The updated glade file
If we decide to use my proposed solution we need to set the minimum width of the gedit main window to at least 560 to avoid window resizing when the replace bar is displayed. Is there a better solution?
Wow, a lot can happen when you ignore bug mail for about a week. Let me try to catch up. comment 1: > While such design brings some interesting points and seems to work great for > apps like gconf-editor, I fear that it isn't adequate in a text editor like > gedit, mainly beacuse it does not deal with search and replace. Ok, but if you're implementing the 'firefox' find system and trying to make it deal with text replace why wouldn't you try to look at my system and try to deal with replace on that? I'm wondering what the problems were with this type of 'eclipse' style search other than the text replace. My point is that the firefox/nedit style find has some nice ideas, but it also has some drawbacks. If we're going to redo the search/replace system we might as well figure out all the drawbacks of each systems and understand the drawbacks to the system we choose. This kind of discussion should probably take place on a mailing list and then a considered proposal be placed in bugzilla.
> My point is that the firefox/nedit style find has > some nice ideas, but it also has some drawbacks. Could you please be more explicit? Which drawbacks do you see? > This kind of discussion should probably take place on a mailing list Well, I do not agree... I don't want to have to read a lot of mails and then archive them. We could eventually send a mail about this bug to the usability ML and continue the discussion here.
I was just thinking about a crazy idea... what about mixing the firefox approach with the eclipse one... I will try to prepare a mockup.
Created attachment 31979 [details] The glade file with the mixed approach
Created attachment 31980 [details] A mockup of the mixed approach
Usability guys: your comment are very welcome
Paolo: I really like this. I think we probably have some minor tweaks to work out, but we're moving is a really great direction.
paolo, any progress on this lately?
I like the mockup of the mixed approach. I would personally prefer to see 'next' and 'previous' as left and right arrows (VCR-style icons). For the replace toolbar, you'd obviously need a 'replace with' field, but also a 'stop'-like VCR button that replaces the current occurrence without moving the cursor on to the next result. Paolo Borelli noted (http://bugzilla.gnome.org/show_bug.cgi?id=100821#17) using Alt-R to replace, then Alt-F to find the next result for each item you want to replace. I think doing Alt-R once for every result but the last, then and Alt-L(ast?) to replace the final entry and close the dialog/toolbar would be more appropriate. Is there a CVS branch with this stuff I can look at somewhere?
the cvs branch with the search bar is called pbor_search_bar IIRC however note that it just has plain search bar (without the mixed approach), also the code there is not that great (it was meant as a quick hack to experiment how such an UI looks like). Note also that the branch is missing the fixes that went on HEAD in the last month or so. Since I don't see it listed in this bug, note that there is also an alternative to the "mixed mode" with the expander: have an "All Matches" button on the search bar that shows the list of matching lines in the output window. With regard to Replace, at the moment we were thinking of using a firefox-like bar only for "Find", while keeping a dilalog for replace, since a replace bar ends up taking a lot of space...
*** Bug 305148 has been marked as a duplicate of this bug. ***
blah... the only practical result of this bug was to rise my bugzilla score :P Anyway... gedit has now incremental search. I think we can close this bug.
*** Bug 343792 has been marked as a duplicate of this bug. ***
Curious about why this has been closed as 'resolved'? Currently, gedit is still guilty of the issues the patch was attempting to address (e.g. find dialog obscures results). Was there some kind of fix, and if so, what was it? I was running the pbor_search_bar branch for months and it rocked. I was very much hoping it would end up merged back into HEAD and made it into future releases. What went wrong?! :)
Created attachment 66719 [details] Altenative design screenshot FWIW, #343792 has a patch with an alternative implementation of a search bar in gedit. It introduces a search/replace bar widget that has an API similar to those of the original search/replace bar. Unlike the previously discussed it has several things done differently: 1. There is no label in the bar - the messages like "n results found" appear in the status bar - this is just the right place for such stuff 2. There is no expander or whatever to toggle replace mode - when a replace mode is requested the second line is simply added with UI for replace that nicely supplement the 1st line (find) and thus turns the bar into a replace bar. 3. There is no 'wrap around' toggle on the bar - instead a notification is shown in the status bar when the search is continued from the top/bottom of the page Despite that it has been told that the bar design introduces some problems, I am convinced that 1) it solves more critical problems than those that it introdices; and 2) most of the problems introduced by this design are not really a big deal. As for window width issue: yes, the width of the search bar prevents the main window from being too narrow. However, the window with the bar displayed is about the same width as 80-column wide text, which is the width most people want to fit in the window. Additionally, the rarely used "Match case" and "Match entire word" checkboxes can be placed in a viewport and don't appear together when the window if too narrow to fit them both at once, but be scrollable with left/right buttons - exactly the same way as you scroll tabs in gedit/firefox/whatever when you open too many of them (tabs i mean).
Created attachment 66727 [details] search-in-panel This alternative uses the bottom panel to settle the search dialog in it. It has advantages and drawbacks. Advantage is that it obviously plays ok with the panes, stays extandable without too much pain, and would probably be implementable as a plugin (at least at first, to test it carefully). The drawback I see is that there is only one "dialog" for both actions (just don't care about the bottom row if you don't want to replace anything, but some people may find it weird). It also looks funny when you have a large bottom panel. In its current state, it stays centered in the pane but does not resize in any way. It could be ameliored by resizing the entries so that it takes the whole panel size. An optional list of found refs could also fill the bottom of the panel if it's big enough. BTW your own ideas are also implementable as plugin (just replace the related menu action to trigger your own code instead of showing the default dialog), so don't hesitate to do so ;-)
As per comment to bug #100821, there should be a way to search and replace inside the selected text only. This avoids having to agonize over what is currently being replaced, for example when you only want to replace words inside a few paragraphs or code inside several functions. I think this happens quite often. There should also be a way to search and replace regular expressions. Otherwise, I agree with comments #27 and #28. There is no need for a "wrap around" check box; when the search hits the end of the document, show a status message and flash the title bar. Hitting the Search or the Replace or Replace All button starts again from the start of the document. This reduces modality and clutter.
*** Bug 559127 has been marked as a duplicate of this bug. ***
I don't understand why this bug is fixed. I still have the ugly search dialog that hides my text in Gnome 2.24.1. Did I miss anything ?