(Warning: This posting has a disrespectful length, I'm sorry. )

As proposed in another thread it makes sense to harmonize search, filter, and highlight functions. And a good starting point might be Kate.

First, we have to talk about the highlighter. This is the find bar below the text (just called internally highlighter to separate the function from a filter applied to lists), which has a replace feature too. Kate works right now almost as suggested by the newly introduced HIG:


Figure 1: Current Kate layout on ctrl+F.

* Type in Find input = Jump to first occurrence
* Enter, Alt+N, F3 = Next occurrence
* Alt+R, Shift+F3 = Previous occurrence

It can be expanded via the green icon, or when called by ctrl+R to:


Figure 2: Current Kate layout on ctrl+R or after expanding.

* Enter in Replace input, Alt+R = Replace next/first item found
* Alt+A, Replace All = Iterate through source
* Find all: Highlight all occurrences
* Remark: The current hotkey Alt+F activates the main menu!

Just a few idea how this bar could get improved:
* Remove 'Find All' and highlight all found items always immediately
* Simple find bar: Hide 'Match cases' to make the bar equal to advanced mode (do case insensitive search by default)
* Advanced bar (aka 'incremental search bar'): Open per shortcut, e.g. Alt++/Alt+-
* Horizontal rule: Move to top for a better discrimination between findbar and statusbar
* Icons for all buttons

Figure 3: Future Kate layout on ctrl+F.


Figure 4: Future Kate layout on ctrl+R.

For discussion:
* Omit left hand Close button (Esc is available)
* Omit 'Selection only' (is right now set automatically when text has been selected)
* Omit Next/Previous and provide short-cuts F3/Shift+F3 only (+ move replace buttons to the mode line)
* Auto complete for input (probably not so good for text)

That would finally look like this (with better icons of course):

Figure 5: Final future and simplified Kate layout.


That was the easy part. With the button 'Search and Replace' below the status bar another pane is shown (additionally to the findbar most likely by mistake). At the moment it looks like this:


Figure 6: Current Kate search layout.

* Enter in Find edit or Search: Generates a list of files that matches search criteria (see below) and contains the text to find
* Next: Browse through matches
* Enter in replace input or Replace: Replace the actual selected text and/or (in case nothing is selected) find next occurrence
* Replace Checked: Replace all occurrences in selected files and found passages
* Folder icon left hand of Find: Open a new search tab labeled with the Find text
* Expand icon left hand of Replace: Switch between result list and search parameters

On click at the expand icon the matching options are shown:


Figure 7: Current Kate search layout when expanded.

* Search: In Folders/In Open files
* Icons right hand of Folder: Open file dialog, Go one folder up, Use current document's path
* Dropdown for Filter and Exclude contain the previous choices
* Enter in all edits starts the search

Since we try to separate the different search functions clearly, the conventional Search operation should be moved to a separate dialog. Search in this narrow sense generates a list of results that will be processed somewhere else. Here is an idea for a generic solution:


Figure 8: Future Kate search.

* Open search dialog per toolbar button, or the like
* Use a 'dynamic filer', this is a user defined collection of key-comparison-value; comparator depends on key, e.g. if 'Content' is selected the comparator > or < will not be available; value selection is supported by constrained inputs like date picker or checkbox lists
* Search can not be executed until a certain condition is met (in case of Kate some content to look for should be entered first)
* Load, Save, Delete to load/save current settings for later redo


Figure 9: Future Kate search results.

* Result list shows findings and provides functions with this list
* Preview for Kate to show current selection

For discussion
* Omit checkboxes: since the search contains all options it makes not much sense to have a filter here again

ToDo
* Better placement of Close button
* Discussion! Please slate me .

I second your ideas!
One of the best search features I have encountered is in Googles Chrome Browser... I absolutely admire the yellow indications on the scroll bar:
(found this screenshot on the www)

Isn't this absolutely brilliant? You immediatly know where to navigate and where to find the most occurences of a search term.

It would be awesome to have this implemented! What do you guys think?

I'd say "Next" and "previous" should be left. Maybe just as arrows. Because at least for me, finding both Shift and F3 on the keyboard is much more difficult than moving the mouse.

Also, the button should probably be called "Search in files" or "Advanced search" to differentiate from highlighting.

GreatEmerald wrote:I'd say "Next" and "previous" should be left. Maybe just as arrows. Because at least for me, finding both Shift and F3 on the keyboard is much more difficult than moving the mouse.

+1, those buttons are really mandatory.

scummos wrote:

GreatEmerald wrote:I'd say "Next" and "previous" should be left. Maybe just as arrows. Because at least for me, finding both Shift and F3 on the keyboard is much more difficult than moving the mouse.

+1, those buttons are really mandatory.

+1 from me for keeping the previous/next buttons as well, those are really standard, though simple arrows (like e.g. Firefox or LibreOffice are using) would soffice, no need for text labels here.

As for the search dialog: I agree it would make sense to have a separate dialog for configuring the search query because then you have more space.
What I think is important for designing this is finding out how people (especially developers) use this feature in practice. Do they have to switch between editing a file and switching to the next file from the search result set often? In that case, we'd have to find a comfortable way to step through the files in the result set (and the occurrences of the string within the files) without having to switch back and forth between editor and search dialog.

I like buttons with text, what is improved by removing the text?

For the find in files thing, for me it's not trivial to make out a use case there; I know lots of people who don't use it at all and instead use git grep or ack (incl. me). I'm not even sure what you would have to do to make me use it. I think selection of the directory to work in is a weak spot, I'm just quicker with that in the terminal. It's difficult because you have to compete with "git grep foo" which takes less than a second to type.

For software development purposes, though, the thing you (or let's say I) almost always want is "find all occurences of this word in my project". I cannot imagine many cases where I would want to use anything more complicated than a wildcard or maybe a regex filter on a folder. Exclude by file type is useful, but exclude by last-modified ... probably has very very few use cases, at least in software development.

scummos wrote:I like buttons with text, what is improved by removing the text?

You get more space for showing longer search queries.

On the other hand, buttons with text labels seem to be the default within KDE, although they're not the default otherwise (see e.g. Firefox, Chromium, LibreOffice...)

scummos wrote:...Exclude by file type is useful, but exclude by last-modified ... probably has very very few use cases, at least in software development.

It is just an example for the flexibility. I want to introduce a generic search dialog that can be reused somewhere else, for instance in Dolphin.

colomar wrote:

scummos wrote:I like buttons with text, what is improved by removing the text?

You get more space for showing longer search queries.

In exchange for a smaller button which is harder to click.

Relevant blog post: http://user-prompt.com/kde-hig-the-search-pattern/

Removing the close button seems like a really bad idea to me. Without it, there's no obvious way to close the search (believe it or not, pressing Escape is not obvious to most people I know).

Also, I've always found the replace bar a bit confusing with its grid of four buttons. I think it would be much clearer if the buttons all were on one row or column.

Nuc!eoN wrote:Googles Chrome Browser... yellow indications on the scroll bar
It would be awesome to have this implemented! What do you guys think?

Isn't it realized right now at the left margin of the content? If not, I'd rather not hack the scrollbar itself but add some additional indicator.

Heiko Tietze wrote:

Nuc!eoN wrote:Googles Chrome Browser... yellow indications on the scroll bar
It would be awesome to have this implemented! What do you guys think?

Isn't it realized right now at the left margin of the content? If not, I'd rather not hack the scrollbar itself but add some additional indicator.

Actually, Kate already (optionally) offers a scrollbar quite similar to the one mentioned by Nuc!eoN, however it shows an outline of the whole content, not just the lines where the search term appears (see http://kate-editor.org/2012/11/03/busy- ... -mini-map/ ).

If the highlighting of the search results is a bit amplified in that "Mini-Map", it might work for that purpose quite well, too!

Yes, that part is a good idea and it would probably be simple to implement. The scrollbar already supports markers for Bookmarks.

Hans wrote:Removing the close button seems like a really bad idea to me. Without it, there's no obvious way to close the search (believe it or not, pressing Escape is not obvious to most people I know).

Yea, that too. Don't forget the people who don't have a keyboard to begin with (tablets and such). While it would be weird to use an IDE on such a device, if we are to have a standard search across programs, the buttons should be visible.

There seems to be good acceptance on figure 4, which is nearly the current state. What I miss a little bit is the discussion about the Search itself (all text below figure 5).

GreatEmerald pointed to an alternate (yet functional similar) approach [1], known from Amarok. Options to look for are provided visually by a list view, and users add them by drag 'n drop, with further specification of the target value. Those who are punished with Atlassian Jira [2] know this feature without graphical support: you type in a key with support of auto-complete and enter successively all 'filter' parameter Google-like (this option is an extension of the simple filter in Jira which consists of a few predefined keywords). Whether or not graphical, in both systems you combine as much options you want logically (AND) to enable complex search pattern.

The second part of the idea in this thread is to have another tab (or however it is presented) with a result list. Operations conducted with those results are offered there. That is in case of Kate the Replace function, in case of Dolphin Copy, Delete etc., and for KMail 'Reply to all', perhaps.

So please criticize both aspects, the search itself and how results are handled. Positive comments are welcome too...