Debugger: Search field to filter images list

[stippi]

It is often too cumbersome to find code in the Images list. There could be a search field above the list. It could filter the entries to the ones matching the search string(s). It would already help tremendously.

[anevilyak]

A question with regards to this ticket: Would it be preferred for the filtering to only apply to the (fully qualified) function names, or the source paths as well? Alternatively, should it perhaps be possible to toggle what's filtered on?

[stippi]

I would keep it simple with regards to options, so I think it should filter on everything, i.e. the string you can see displayed on the items in the outline list view. But it would be nice to support searching on multiple words and the item strings need to contain all search term. The search feature should be designed to reduce the list entries so one finds a particular entry faster. It shouldn't matter whether the search can be specified to be very precise, IMHO. It should also not consider case for the same reason. The goal should be to add just a single text field for entering search terms and any option that's not possible to specify with just the text field would not be possible. On the other hand, the feature should get "the most" out of having just a single text field as interface.

[stippi]

Thinking about it some more, if an entry matches because of its fully qualified function name, the entry should not be hidden, because its parent entries with just path names do not match. However, if I want to see just the entries under a certain path, it would be nice if that worked as well, but without having to be configured.

[anevilyak]

A few more questions while I work on the initial implementation of this:

1) Is the simple matching outlined above sufficient, or would e.g. regular expression support be desirable?

2) Should this be live in the manner of Tracker's type-ahead find or would it be preferable to execute the filter once the user finishes typing and hits enter?

and 3) How should we ideally show the filtered results? One possibility that comes to mind is to auto-expand the tree nodes to show the subpath/file in which the functions that match were found, but if the match actually hit the source path rather than a particular function then that wouldn't necessarily work quite so well. Another possibility that comes to mind would be to switch to a flattened view when filtering or something in that vein, but I'm not sure? Any other thoughts/ideas?

[bonefish]

TBH, I think the list view is way too small to be really effective. Even if you squeeze the search field besides the horizontal scroll bar to avoid losing even more space, the view probably won't be higher than 10 to 15 lines. Considering that a tree structure is shown, we lose one line per path component and possibly get very sparse results. The view also isn't particularly wide.

One can resize the view with the splitter, but the more interesting parts are the source and the variables view, so it's generally not desirable to do that. When searching for a file/function one wants a larger view, otherwise a small view is fine. When entering the search mode (via shortcut/button) the view could become larger temporarily. Or the view stays as it is and the search functionality is implemented in a dialog. E.g Pe's "Find Function" dialog does something rather similar to what we might want here.

Regarding your questions:

1) I think regular expressions would be overkill and possibly even inconvenient to use. Support for simple shell glob patterns (particularly "*") would be nice, though. Partial matches should suffice, though, so that one doesn't have to prepend and append a "*" when searching some substring in the middle.

2) The search should be live.

3) Not sure. If the multi-level tree view is kept, I would expand the nodes up to the component that matches. If subcomponents don't match, remove them. If implemented in a separate dialog, I would then support invoking (i.e. double-clicking/selecting+Enter) directories or files. The dialog would then restrict the search to that directory/file and clear the search string, so that one can quickly narrow down the search in case of big libraries/applications. Flattening the paths (but keeping a second level for the functions) might work as well. One could use the fact that the whole path is matched and e.g. use "/su" to find the support kit sources in libbe.

[anevilyak]

Replying to bonefish:

TBH, I think the list view is way too small to be really effective. Even if you squeeze the search field besides the horizontal scroll bar to avoid losing even more space, the view probably won't be higher than 10 to 15 lines. Considering that a tree structure is shown, we lose one line per path component and possibly get very sparse results. The view also isn't particularly wide.

Indeed, I'm not really sure about an easy way around that at the moment though. One possibility would be to give the image function view its own tab, but that would render the current strategy of having the images to choose from on one side with the corresponding set of files/functions on the other a bit less workable. I'm not really sure what a better alternative would be though, unless we want to simply remove that tab entirely and have that subset of functionality accessible via a menu item / keyboard shortcut that pops up a separate window for just the image-related components.

1) I think regular expressions would be overkill and possibly even inconvenient to use. Support for simple shell glob patterns (particularly "*") would be nice, though. Partial matches should suffice, though, so that one doesn't have to prepend and append a "*" when searching some substring in the middle.

Noted.

Attached please find an initial implementation based on Stephan's original suggestion. This one is live and expands matching nodes, and does a partial (case-insensitive) match based on the input string. It does not do shell wildcards at the moment though, but that could easily be rectified. Please give it a try and let me know what you think of the behavior as a start.

[stippi]

I'm in Haiku checking out the patch. It works pretty much like I imagined. There seems to be a bug which expands entries right after one manually collapses them. One can collapse again and it will stay collapsed. Other than that, I think it really needs to highlight the matching portion in the list entry labels. And maybe it could remove all leaf nodes (methods) which do not contain matches. But that change would require that clicking a source file parent node itself also opens the source in the source file viewer, currently that requires clicking a method leaf-node. (Direct hits for source file names which do not have matches in methods could otherwise not be opened.)

I do understand Ingos concerns with regards to how much room the filter interface takes (about 2 lines in the list view right now). In theory, one could make the filter interface closeable. All Debugger views could get this functionality. Some of them would have the filter interface shown by default, like the right side Images list. In the Edit menu, there could be a Find entry, which could show the interface in the view which has focus. This could of course also work in the Source view where it makes just as much sense. What do you guys think?

[stippi]

Replying to bonefish:

When searching for a file/function one wants a larger view, otherwise a small view is fine. When entering the search mode (via shortcut/button) the view could become larger temporarily. Or the view stays as it is and the search functionality is implemented in a dialog. E.g Pe's "Find Function" dialog does something rather similar to what we might want here.

The intuitive thing for me is that I look at the right Images list and see an overwhelming list of entries. I don't think about a separate dialog to search something, I think about a way to reduce the number of entries in that list. In effect, I am not searching, I am filtering. As such, a separate interface would be besides the point (at least for me). I agree that having to expand the entries to even show the filter result is a problem since it can take up even more space than the initial collapsed list. I think highlighting the matches balances that problem a bit, since even though the list still contains many entries, one can still quickly see the interesting ones. Another option could be to switch from the new tree representation to the old flat list while filtering, and then really remove any entry that has no matching port in its label. I think that could work well.

[anevilyak]

Replying to stippi:

Another option could be to switch from the new tree representation to the old flat list while filtering, and then really remove any entry that has no matching port in its label. I think that could work well.

I actually like this idea, and gave it a try. Attached 9755-2.patch does so. Let me know what you think. Highlighting the filter match will take a bit more work so that isn't done yet, and I'm still looking into what causes the odd collapse/expand behavior you mentioned.

[anevilyak]

Updated version of the patch attached which fixes the collapse behavior problem. Please give it a try and let me know if the flattened tree representation when filtering is preferred or not, and in the meantime I'll start looking into the highlighting.

[anevilyak]

Highlighting implemented in 9755-4.patch. Let me know if that looks good, and if so I guess we'll go with that for now.

[anevilyak]

Found/fixed some more bugs and optimized things a bit. Also used Ingo's RegExp classes from Ham to implement shell-style wildcard matching rather than just simple string matches. Merged to master in hrev45743.

If anything else is desired as regards these features, please let me know.