Heiko Tietze wrote: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.

What I like about the Amarok filter configurator is that it can accomodate Berna as well as Philip (see KDE Personas): Berna can create the filter in a visual way without having to know any operator signs, whereas Philip can still hack together a filter condition using his keyboard quickly.

As I'm the author of the Search & Replace plugin I feel I have to explain my self a bit or the reasoning for why the things are like they are

The built-in search dialog was a modal dialog in the KDE 3 times and was changed to the current search-bar to avoid having the text to search for underneath the dialog. It has gone through many iterations to get an optimal size and functionality. I think it is very hard to simplify without loosing functionality. I will let the others in the Kate team comment more on that one. I'll concentrate on the plugin.

The Search & Replace functionality is provided by a plugin that does not know about the KTextEditor internal search bar. That is the reason you can get both at once. Kile and KDevelop that that use the KTextEditor component do not have the plugin. I'll add it to my todo to see if it would be easy to have the searches close the other one when invoked.

The previous Find in Files plugin was a separate dialog and it meant that when the dialog was opened it covered the text that we was supposed to search for. This is why the new one is not a dialog and I would really not like to make it a dialog again. It is a piece of UI that is almost always open when I code and having to move it around to see the text is not something I want to do.

"Dynamic filter": I'm a bit skeptical The UI would become quite big...

"Search can not be executed until ...": this is a bug that I'll add to my TODO list.

"Load,Save...": The current plugin saves the search settings in the session.

"Preview": Having the UI integrated in the editor window means that there is no need for a separate preview as the match can be reached by double clicking the item. All the highlighting already applied

"Omit checkboxes": it would be very cumbersome to generate a filter for replace all "Foo" in FooBar.cpp and bar.h but not in Foo.cpp and Bar.cpp. And if I notice that one of the matches not should be replaced it is much easier to remove one tick than to try to rewrite the filter/regexp to omit that specific match.

That said I think the Search & Replace is very specialized and can be quite hard to cram into a generic search dialog. But the UI as it is does need some love. For example it is a bit cumbersome to reach the filtering and regexp options once you have found a match. The "more options" button is a bit small....

sars wrote:KDevelop that that use the KTextEditor component do not have the plugin

Or rather, we have our own implementation of "find in files" which does pretty much the same than yours.

I agree with Kare's points, esp. that the Ctrl+R search bar is very very good already. About the dialog I can't say much, I never use that

I'd like to draw a preliminary conclusion based on the discussion here and at the mailing list:
* Next and Previous should be available as labeled button for sake of accessibility and self descriptiveness
* Match cases is required in Kate because the feature is use frequently (it predominates the disadvantage of jumping layout when the panel gets expanded)
* Find All cannot be omitted because it takes too much time for large files when applied always (via Find), and Find is expected as it works now
* Search (and replace) should stay inline for iteration purpose; editing a bunch of files usually comprises of repeated actions

* Find/Replace and "Search and Replace" open at once has been considered as bug
* Using a dropdown with all options (instead of checkboxes) as used in most other applications has the drawback to inherit the settings. This could be counteracted by a set of icons (so it works like a group of toggle buttons) but it still would lack on keyboard access.

Kate is "a power user advanced text editor", not designed for the average user. Kate devs have a lot of good points to keep the layout as it is. Thank you guys for the discussion!

Heiko Tietze wrote:* Find/Replace and "Search and Replace" open at once has been considered as bug

It's not exactly a bug, but an architectural problem: The "Search and Replace" dialog comes from a plugin which doesn't know whether Kate's own Find/Replace dialog is currently open. The team is aware that this is a problem that should be fixed, but it's more than a mere bug.