Redesign search dialog

[pkulchenko]

The search dialog is currently shown as a popup window, but it would be useful to (1) make it dockable, (2) make it more compact, and (3) add support for incremental search.

Other search-related tickets: #398, #146, #162, #140, #132, #127, and #147.

[pkulchenko]

The updated dialog window is always docked. I initially tried to make it floating and dockable, but there is an issue on OSX and Linux with getting focus to components on floating windows that have wxFRAME_TOOL_WINDOW style, which is exactly the style that wxAuiManager is using for its floating windows (and it's not configurable).

Another wxwidgets issue made it difficult to use wxComboBox components as they don't handle key events properly on OSX, which makes Tab and Escape key handling difficult.

So far I've kept the current functionality, minus the ability to select from comboboxes, which I plan to compensate with suggestions from most-recently-used list in the text field.

The added functionality:

1. Incremental search for Find and Find and Replace. The text is searched as you type
2. Esc is used to close the form; the cursor is left at the current position. If you want to restore the cursor at the original position (when the form was opened), use Shift-Esc.
3. Enter in Find field does search, Enter in the Replace field, replaces one instance.
4. The status bar was moved to the search toolbar, which makes the message more visible and convenient there.

[pkulchenko]

@sladecraven, @kspes, @andrewstarks, @Fringale, @stuta, @easy82, @naturally, @pixeljetstream: I've been working on a complete search redesign and would welcome your feedback. All of you provided search related comments and suggestions in the past and I'd be interested in how the new search works for you.

There were several goals for the redesign:

1. make the UI more similar in style to the rest of the application, which has changed significantly while the search/replace dialog stayed the same,
2. preserve the existing functionality and extend/improve it in several ways,
3. make the dialog simpler and more compact,
4. add incremental search,
5. show find-in-files results in an editor tab, and
6. add preview for replace-in-files.

The last two items are still being worked on and should be available in few days, but other items are done and have been pushed to search-redesign branch. If you use ZBS cloned repo, you can do git fetch origin; get checkout search-redesign. If you prefer to not use git, you can get the latest search-redesign code in a .zip archive.

I also plan to add search/replace in open files and search/replace in selection, but these two will be done a bit later, after results-in-editor-tab is implemented.

I combined directory and mask fields into one field and you can specify one directory and multiple masks (separated by semicolon or comma). The directory is optional as the current project will be used if not specified, but will be suggested by default to show how it can be used.

The only thing that got "lost" in the redesign are the dropdowns as they have several (wxwidgets) issues/limitations associated with them (see my earlier comment in this ticket for details). I've tried to compensate in the scope field with the toolbar dropdown, but search/replace fields don't have anything to access earlier searches. I'm considering several options:

1. do nothing.
2. provide autocomplete that shows matches based on most-recently-used history. If you previously searched for foo and type f, then oo will be added and selected, so you can type over it. There are couple of issues with this as some users may not like matching (so it needs to be configurable) and it may interfere with incremental search (it will try to find foo even though you may have something else in mind).
3. use up/down arrow keys to access the history of previous search strings. Not too difficult to implement, but may be difficult to discover, so it's likely to be rarely used.

I've been using option 2 in other products and it works quite well, but I'm open to other suggestions.

Give it a try when you get a chance and let me know your thoughts. Thanks!

[kspes]

Hi Paul,

Finnaly found some time to evaluate the new branch, here are my thoughts
and comments:

1. Love it! It's now way more practical to use!

2. Still get ocasional mini freezes while searching but nothing major.
   especially when searching for a common word in a large projects (such as
   "function")

3. If you quit the app while search is still active you get a lua crash

4. the filter is not remembered properly after re-launching the app. I set
   it to serach for .lua;.scene;*.dlg, and it always defaults back to *.lua
   for me, regardless of whether I separate it with commas or semicolons.

5. Speaking of slowdowns, the "Go to file" dialog is horribly slow for me,
   down to the point I can't use it. and I used it on a powerful PC as well as
   a laptop. I figure it's because it's searching a lot of binary file I have
   in my source tree, any ways to optimize the search?

Krešo

[pkulchenko]

1. Love it! It's now way more practical to use!

@kspes, thank you for the feedback; good to hear it's working well for you! I'm almost done with showing results in a separate editor tab, which should be much more convenient as well.

2. Still get ocasional mini freezes while searching but nothing major. especially when searching for a common word in a large projects (such as "function")

I'll see what can be improved, but if it's a general search (not a binary file), there is probably not much I can do without drastically changing how the search is done.

3. If you quit the app while search is still active you get a lua crash

Is it during find-in-files or the current file search? I'll check...

4. the filter is not remembered properly after re-launching the app. I set it to serach for .lua;.scene;*.dlg, and it always defaults back to *.lua for me, regardless of whether I separate it with commas or semicolons.

Yes, this information is not saved between sessions, but will be. I'm not sure how to show the custom filters as they are going to be in the history, but would you expect to show your filter or the default one? I can probably find the most-recently-used scope based on the the same project path and apply it (instead of the default value). Is that what you are looking for?

5. Speaking of slowdowns, the "Go to file" dialog is horribly slow for me, down to the point I can't use it. and I used it on a powerful PC as well as a laptop. I figure it's because it's searching a lot of binary file I have in my source tree, any ways to optimize the search?

Yes, I'm thinking about several improvements.
(1) Read and check only the first 2k,
(2) Keep track of extensions for binary files; if I find two .exe files that are binary, it probably doesn't make sense to read any exe files, so I can just filter them out (same for binary files without extensions or images and so on); and
(3) Add configuration for folder/file exclusion. This would apply to everything (including showing files in the project tree and any searches); this will speed up search and go to file navigation as those files will be simply skipped.

Let me know what you think may work better for your case...

[kspes]

HI Paul,

remembering the last filter used for each project would do fine in my
configuration. But I really think you're going to have to use a
project/workspace file sooner or later, to store either project specific or
user specific values.

as for Go to Files, I like those ideas! It's important to be able to define
what a binary file is if you can't autodetect it. for example I have a
proprietary image format I use than is binary, which probably won't be
included if you define a list of file extensions that are binary.

also, I know some devs that use .dat files to store tex configuration info,
while some use it for binary data.

Krešo

[pkulchenko]

also, I know some devs that use .dat files to store tex configuration info, while some use it for binary data.

Right, what I have in mind should still work fine for that because it will be remember for each session (I'll keep track of extensions for binary files and if the same extension is detected twice, I'll skip it in the search).

BTW, I can't reproduce the crash with quitting while searching. Is it during find-in-files? Do you simply close the application while the search is still happening?

[kspes]

yeah, I do a cmd+q (mac) while searching and it crashes.

here's a screenshot:
https://www.dropbox.com/s/csdrb333yrycqfc/Screenshot%202015-03-22%2022.21.28.png?dl=0

Krešo

[pkulchenko]

Thanks; this is running the latest commit (2406863) in the search-redesign branch, right?

[pkulchenko]

@joe528, I added search.autohide option, which you can set to true to hide the search panel after find-in-files operations.

[pkulchenko]

@kspes, I've made several improvements to file traversal that should improve performance in command bar and file searches. I've also added exclusion lists and binary file lists (#455) that you can extent to skip the files or folders you don't need searched. Give it a try and let me know if it's any better...