Kate searching preview 2 2007-08-09

Here is my current idea for the power search and replace dialog (click to enlarge):

The shortcut keys (underlined letters) must not conflict with those used by Kate’s menu, which became a little tricky. I am wondering how we will solve this problem for other programs using KatePart – what if they use some of these shortcuts for the menu? Here is the updated Firefoxy one:

Comments welcome.

[EDIT]: Dialogs were just “drawn” with Qt Designer – they are not integrated yet.

Serhiy August 9th, 2007

First when firefox introduced their new search bar at the bottom of the window I liked it. But now I tend to think that when this search dialog appears at the bottom it is not very “recognizable”. I mean that you don’t pay much attention to the bottom of the page and if you don’t know that find dialog should appear at the bottom you can gust miss it. What if try to place the same dialog at the top of the page? I am not 100% sure that this is a good idea but we can experiment with this.
Or maybe you can wok with guys from http://openusability.org/ to get the deep analysis.
As for me it will be great to have search dialog design similar for all KDE applications.


Soxofaan August 9th, 2007

Looks good. I also prefer the firefoxy thing way above the modal dialog.

Why is ‘highlight all’ a button instead of a toggle checkbox (like in firefox)?

Soxofaan August 9th, 2007


What if try to place the same dialog at the top of the page?

I remember reading about the research that the firefox devs did on this. I recall something like that if you put it at the top of the window, you have a higher chance to hide interesting parts/parts that are being read. Moving the text down, so the top of it isn’t hidden introduces shaking of the text, which looks bad.

Vincent de Phily August 9th, 2007

Why use a toggle-button for “highlight all” and a checkbox for the other options ? Looks inconsistent, for no reason that I can see (the behavior/meaning is the same for both widgets).

Enabling search history in the simple mode seems clean enough (UI-wise) and usefull.

On the other hand, I feel the “match case” option doesn’t need to show up in simple mode (the need for case-sensitive matching is rare enough IMHO).

As for the “highlight all” feature itself… Why would anyone want to disable it ? Speed concern ? I’m sure you can make it responsive enough. Visual clutter ? Use a dimer highlight, or some safari-style highlight. Please leave “highlight all” allways on, and remove the option.

Disclaimer: I’m a happy emacs user. Tried kate a few times but its inferior search and autoindent features are big showstoppers. Good to see search is being solved, thanks !

kollum August 9th, 2007

Hy. for the location of the bar, what about a docked one ?
I mean a la Koffice flake tools, or actual menubars ? The first time, it would apear in the midle of the screen, but you could drag it to the top or bottom as you prefer, or let it floating.

The second Idea would be a popup with a ‘never show me again’ button to say ‘hey, look at the bottom of your screen, you may find chocolate’

Joachim Werner August 9th, 2007

I like the mockups. But there’s one thing I think you should keep in mind: This kind of search is not specific to kate. It is already used in browsers (not only Firefox, but (not done as nicely) in konqueror, too. And it makes sense in the filebrowser, menu (the SUSE start menu has an incremental search) etc.

So the solution you choose should ideally share code, but at least share the look and feel with other KDE apps that have a similar need for incremental search.

sping August 9th, 2007

Using the Firefoxy one for other applications: In Kate we can make one bar so simple that it cannot do complex things anymore because there is its big brother with strong muscels, but if we put that Firefoxy one as the only search dialog into other applications than that app will have very limited searching only. A friend of mine sees incremental search for navigation only: to jump to a certain word in a document or to check if a word is even there. In any app where searching does more than just navigation we will need more power I guess. John Lennon agrees with me here: Power to the people! 😉

Search bar on top (not bottom): I fully agree that the document moving down is a bad thing. Will see if I can talk to a usability expert on the dialog in general nevertheless.

First time “user, please look down” message: Good idea! For Kate that message could even briefly introduce the two dialogs.

Highlight all not as a checkbox: It’s a toggle button as in Firefox I think the difference with that control is that it finds additional matches while the real checkboxes control what’s the first match to find.

Highlight all always on, with no button for it: With this setting I think we would lose the ability to concentrate on a single match. Question is if that case is 50% or just 5%. Anyway we will need some update delay for highlight all to solve the speed problem since the whole doc is search for every single keystroke otherwise.

Match case: That’s an interesting idea. I don’t remember ever switching it on in Firefox.

Search history: Search history doesn’t go well with incremental search in my eyes. That was one of the key reasons why we turned to two different dialogs. (We went for an incremental version of both dialogs in one before.)

Kate “showstoppers”: Vincent, afaik Dominik Haumann is working on indentation related things currently. Have a look at his blog.

Bar in docking mode: It might be an option for apps with just that incremental bar (and making it show all the time) but I don’t think it goes well with the two bars concept and Kate.

Thanks for all the feedback!

Fred P. August 10th, 2007

Please use a search and replace dialog similar
to http://www.editplus.com/

It also looks similar to your current proposal,
except that yours is shown at the bottom a la sauce Firefox 🙂

You can try it out with wine it works out of the box.

It allows regexp, multi line search and replace,
multi line, regexp search and replace in all open documents…



Multiline in Japanese:


Kai August 10th, 2007

overally a good concept
I personally don’t like the exit button:
a) too small (good chance to miss it with a click)
b) strange (no?) alignment in the extended view
c) i hope you thought of the ESC hotkey which makes the search bar go (in firefox) so you’re not forced to change between mouse and keyboard to make it go away

ben schleimer August 10th, 2007

Why not separate the find dialog from the replace dialog? Then you could have a simple find and eliminate the advanced dialog.

From a users POV, it doesn’t make seem to suddenly have the option to replace in the advanced dialog and not have it in the simple one.

About the “Selection Only” checkbox, how often is the user going to select text and want to replace outside of the text? I think it’s an extranous check box.

Also the highlight all seems extranous. I thought the whole point of incremental search is to find the first match, and then the next, etc.

Actually, this points out why separating find and replace is important. Replace needs more UI research. Like, how to do “Replace All” verses “Replace One at a time”? Maybe make “Replace All” into a modal dialog.

Good work anyway, I like the regular expressions verses plain text. (If there are no other find modes, you might want to make it into a checkbox…)

sping August 10th, 2007

Close button: Making it larger also gives even more attention to it and wastes more space. For now I’d think it should stay that way

Escape key support is planned of course.

@Ben Schleimer
Seperating search and replace:
The power search dialog is actually meant to do searching and replacing for you. The replace dialog cannot work without searching in it so I’m not sure what we should split here.

Selection only: I’m switching this on/off on a daily basis myself.

Highlight all: Other people would like to see all matches being highlighted all the time. In my eyes your two views on this shows the need for that button.

Combobox: There is two other search modes – whole words and escape sequences. For just two I would have used a checkbox of course.

Vincent de Phily August 12th, 2007

search history: The “editable dropdown box” (like the alt-F2 dialog) widget seems like a good fit to me. Search incrementally while the user is typing. Add to the search history when the searchbar closes (and when a “replace” is made ?). What doesn’t go well ?

highlight all allways on: Funny to see somebody has the exact opposite opinion from mine 🙂 If Ben is serious about it, then the toggle/checkbox is necessary indeed. However, I wonder wether he (everybody) realize that the highlighting of the “current find” is supposed to stand out from the “all finds” ?

toggle/checkbox: I just looked at the firefox “highlight all” button and can’t see the behavior you mentioned, or any reason to divert from the traditional checkbox. I can imagine somebody somewhere has a good reason for that, but I didnt see one yet.

sping August 12th, 2007

@Vincent de Phily
search history: One problem is that there is no clear distinction beetween single searches anymore. Say I am typing “one”, then extend it for ” million”, and then delete the million part again: I did two different searches, but how does Kate know? Only “one” would end up in the history. The example is a bit constructed but I hope it helps to show my point.

toggle/checkbox: I’m not sure what you mean. Here is a shot of my Firefox searchbar on Windows, one as a toggle button, one as a checkbox:


As I said somewhere else before I think the difference is that highlight all does additional searching while all the checkboxes control what the first search will hit. To me highlight all is more a command than a modifier.

[…] then progress has been made: Florian Grässle of OpenUsability strongly improved my original dialog drafts and I started implementing the improved dialog mockups. What you can see below are actual […]

Leave a Reply

You must be logged in to post a comment.