Hi.

The current interface seems awful for me.  Below I describe what I consider wrong and suggest some solutions.

This issue was already raised in another bug report [1], but that one isn't about the search interface as a whole, so I decided to create a new one.


In the text below I use some "terminology".  Here is the summary:

"the list"
    the list of search types ("Subject", "Author" etc.)
"the interface"
    the search interface
"next/prev keybindings"
    Ctrl-G/Ctrl-Shift-G to go to next/previous match


Now, below is the list of problems I found.  For each problem, I assigned a number (0-3) to indicate how critical the problem seems for me.  The criteria behind the number are
- usefulness of the proposed solution for me (0-1);
- how hard it is currently for an ordinary user to find the feature, related to the problem, in absense of the solution (0-2).

1. There is no way to activate the list using keyboard, though there are key bindings for every other functions of the interface (sometimes keyboard is even the only way to achieve something, e.g. next/prev keybindings).  Moreover, it isn't obvious that an icon will open a list (isn't it prohibited in GNOME HIG?).  I would prefer a more convenient interface (see after this list), which obviously allows keyboard access {3}

2. There is no separate "Search"/"Find" button, incremental search is used instead.  For me it's perfectly OK except one issue.  Sometimes I need a way to repeat the search (from the first match).  In current interface the only way to achieve this is to modify the criteria and then undo (e.g., add and remove a space), so the incremental search runs.  I suggest that search is repeated when Enter is pressed; I believe this behaviour is quite common. {1}

3. There are no "Next" and "Previous" buttons, instead next/prev keybindings are provided.  There are two subproblems with it:

3.1  An ordinary user may be unaware of the keybindings, so there should be a thing in an interface to tell her about them.  Two possible solutions:

- Add to the top menu a submenu Search containing Next and Previous items with labels describing their corresponding keybindings.  I don't quite like this as the items will be disabled most of the time.

- Add Next and Previous buttons (with hints about the keybindings).  It seems hard to include them in the interface in a way that the result looks acceptable.  A solution would be a Firebug-like search panel [2], but it can be hard to implement with GTK.

The number (for any of the solutions): {2}

3.2. Though the keybindings are available, a user may prefer using buttons (does GNOME HIG recommend "mouse accessibility"?).  It is another reason to include "Next" and "Previous" buttons. {0}

There is an alternative solution for all of 3, 3.1 and 3.2.  It is to filter the commit list dynamically to match the search criteria, as suggested by Jesse at [1].  This completely eliminates the need of Next/Previous movement distinct from ordinary Up/Down in the commit list, and the behaviour is quite intuitive.  However, there may be performance problems with it.


A version of the interface I would prefer:

            +------------+ +--------------------+
    Search: | Subject  v | |                    |
            +------------+ +--------------------+


Personally, I found the list and next/prev keybindings by experiment (the list by clicking everywhere, and the keybindings by trying traditional F3 and then Ctrl-G).  I even googled a bit about how to go to a particular SHA, which is a sign that the current interface is not intuitive (or I am not so smart as other gitg users :).  Hope this long text will convince you developers to spend some time on the search interface :)  

[1] "Search bar only lets you find the topmost matching commit"<https://bugzilla.gnome.org/show_bug.cgi?id=596770>

[2] <http://getfirebug.com/img/whatisfirebug/searchAndYouShallFind.png>


Cheers