Bugzilla – Full Text Bug Listing
| Summary: | Search View: Auto-Expand (was: Expand All missing from Context Menu) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | DaveLaw <Bugzilla.eclipse> | ||||
| Component: | Search | Assignee: | Stefan Xenos <sxenos> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | cadenhowell, daniel_megert, eclipse.sprigogin, sxenos | ||||
| Version: | 4.6 | ||||||
| Target Milestone: | 4.7 M1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 10 | ||||||
| See Also: |
https://git.eclipse.org/r/#/c/77798/ https://git.eclipse.org/r/77798 https://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=a3473afca079bd58582491f2e17a888829c11d42 |
||||||
| Whiteboard: | |||||||
| Bug Depends on: | 509831 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
Expand all was removed as part of bug 477471. I believe the main use case of the "expand all" action is to be able to minimize the user gestures required to drill down to the leaf nodes where the real content is. I think another way to address this would be to always auto-expand nodes in the search view containing only one child. That would be even easier to activate than the expand all action but would be more selective. Patch attached. It doesn't bring back the "expand all" action, it just changes the normal expansion gesture into an auto-expansion gesture, which should eliminate the massive click sessions in an even more convenient way than the old "expand all" action did. I believe removing "Expand All" in the first place was an over-reaction. As Lars Vogel observed, it was a little unclear what to expect of "Expand All". But actually only a little unclear. The actual problem is, that the Search Results have no (visible) root element. The correct response would be to make the root node visible. Then a selective "Expand All" on a particular Node would be available. The function could then possibly be renamed "Expand Node". Just delivering the results pre-expanded causes other problems. I would prefer either to see "Expand All" reinstated as it was, or a proper solution as I suggested above. We just submitted the auto-expand patch. It should show up in builds shortly. It only affects the File search pane (Search -> File...), and I think it will fix the click sessions. If you feel that it sorts out your massive click sessions, please mark this as fixed. > Just delivering the results pre-expanded causes other problems.
I must not have explained the auto-expand feature. It doesn't deliver the nodes pre-expanded. It auto-expands nodes that only have one child (such as the folders for parent packages in java), so when you open - say - your "src" folder, it will immediately also expand subfolders until it reaches a folder where you have a choice to make.
Give it a try if that doesn't make sense.
Auto-expand doesn't change the set of nodes which are expanded when you first open the view. It changes how many nodes open when you manually expand a node. New Gerrit change created: https://git.eclipse.org/r/77798 Gerrit change https://git.eclipse.org/r/77798 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=a3473afca079bd58582491f2e17a888829c11d42 Should this bug be considered fixed? Yeah, let's mark this fixed since we've addressed the massive click sessions, which I believe were the main problem being reported here. If we still want to make further improvements we can open a new bug for the follow-up work after folks have had a chance to try the new behavior. Just hang on a second there: how can I try this out? -> tonights 4.6 Maintenance build? -> 4.7 Nightly Just hang on a second there: how can I try this out? -> tonights 4.6 Maintenance build? -> 4.7 Nightly? According to the git tags, this change should be in build I20160726-0800. I'm still downloading it to confirm. I can't find any useful improvement in I20160726-0800. ok, I've now compared 4.5.2, 4.6.0 & 4.7.I20160726-0800. The change in I20160726-0800 is minimal & of no real use. If you have a large search result, you need "Expand All" to avoid a click orgy. I'm sorry if I accidentally hijacked your bug, but this bug is permanently associated with the git commit that added auto-expand to the search view. We'll have to file a new one to track additional work rather than reopening this one.
> The change in I20160726-0800 is minimal & of no real use.
In my testing, it reduced the number of clicks by a factor of 5 on average.
My test case:
I used Search > File and searched for the word "public" in the java files from the Platform UI repository, and counted the number of clicks needed to open 5 search results (I used the same results in each case)
Results:
With auto-expand: 18 clicks
Without auto-expand: 38 clicks
With expand-all: 15 clicks
Comparing auto-expand with expand-all: with auto-expand there were no nodes expanded that were unrelated to the search results I opened so I spent less time scrolling. Also, the click targets were much closer together than with expand-all... in my opinion, this more than made up for the 3 extra clicks.
Four results were at tree-depth of 8 and required three auto-expand clicks to navigate to, one result was at tree depth 2. Running expand-all required right-clicking, left-clicking, then double clicking to open the final results, so three clicks per result.
Could you describe your test case in more detail, so I can better understand the reasons why it is not useful?
> In my testing, it reduced the number of clicks by a factor of 5 on average.
Sorry. Typo. I meant 0.5.
If you have many projects in the work space & hits at varying depths you can spend all day clicking them open. (its much easier to close expanded nodes than to open collapsed nodes, because you can see at which level you want to close an expanded node) Thats the way I like to work: expand all, then collapse what I've checked. After checking, the search should be fully collapsed & I know I'm finished. But of course everyone likes to do things differently. So please give us back the "Expand All" functionality. Does your "hijack" remark mean we have to open another request for this? > If you have many projects in the work space & hits at varying depths > you can spend all day clicking them open. So you claim, but in the test-case I described, above, expand-all took about the same number of clicks as auto-expand, and took fewer actual gestures once you include scrolling. Clearly I'm doing something differently in my tests than you did in yours. Could you explain what you're doing differently so that I can reproduce the case where expand-all outperforms auto-expand? > (its much easier to close expanded nodes than to open collapsed > nodes, because you can see at which level you want to close an > expanded node) Yes, that is true. But in the examples I've tested it is true with both auto-expand and with expand-all to largely the same degree. > Thats the way I like to work: expand all, then collapse what I've checked. You start with the view fully expanded? You can still do this with the toolbar button. I was using a selective expand-all in my tests, which is what was removed. > After checking, the search should be fully collapsed & I know I'm finished. If what you're missing is a method for marking search results that have already been visited, the view has a mechanism for that. The "remove selected matches" action - bound to the Delete key by default - does this. > But of course everyone likes to do things differently. > So please give us back the "Expand All" functionality. Unfortunately, the fact that there exists some user that liked using feature X is not a justification for keeping feature X. It is always true of all features, so doesn't help in determining what features to keep. What we need is a realistic and reproducible use-case that can't be addressed efficiently with the current feature set. If we had such a use-case, we could discuss what sort of feature would do the best job of addressing it. Since you don't seem satisfied with the auto-expand replacement, please file a new request. When you do, describe your use-case in sufficient detail that someone can confirm that auto-expand was indeed the most efficient workflow. If it was me evaluating the feature, I would want to count user gestures - so detailed steps to reproduce (or a video) are far more convincing than a phrase like "it takes me all day without it". Even if the latter is literally true, it isn't helpful to a third-party unless they understand exactly what you were trying to accomplish. > Does your "hijack" remark mean we have to open another request for this? Yes. (In reply to Stefan Xenos from comment #16) > I'm sorry if I accidentally hijacked your bug, but this bug is permanently > associated with the git commit that added auto-expand to the search view. Next time please don't use wrong descriptions in your Gerrit changes: Bug 498319 - Search View: Expand All missing from Context Menu was completely unrelated to the fix. > was completely unrelated to the fix.
Consider me suitably admonished.
(In reply to DaveLaw Missing name from comment #18) > Does your "hijack" remark mean we have to open another request for this? Did you open another request, and if so, could you include the number so I could vote for it? Thanks. Caden, could you explain your use-case where expand all is more efficient than the new autoexpand behavior? I do most of my work in a workspace with 30 Eclipse projects in it; this is the standard for my team and a requirement for my work. This is for a large 10+ year old legacy Java project. When refactoring, for example, I want to do a search through all of the projects to make sure I'm renaming all instances of code related to some concept. Some search terms are overloaded and it takes several tries to get a useful query. Sometimes it's easier for me to scroll and skim through 500 results than it is to find a more specific query. Before Neon, the first thing I would do after every search was right click in the window and choose "Expand All", so I panicked when it disappeared. I will say, options like "Expand All" are more discoverable in a context menu where I can read all of them, rather than mouseover each of the icons in the top of search results window to see what they are. The layered plusses and minuses did not suggest to me expansion and collapse. Would you believe that I went to StackOverflow and found the solution there (click the layered plus signs) rather than finding it in the interface? That's what happened, after I added my previous comment. For me, the problem is solved, since I now know how to expand all without the right-click menu. It's possible other people are running into the same problem I did but I no longer have any personal interest in it. Like Caden, I have a Workspace with a fairly large number of projects. I gave up on this issue after being asked to provide a use-case for the blindingly obvious. Having discovered the Expand All button in the Menubar, fighting this cause just became too much of an uphill struggle. I remain of the opinion that the Expand All Context Menu Item was of great use and find Lars Vogels reasoning for removing it in Bug 477471 quite unfathomable. > I gave up on this issue after being asked to provide a use-case for > the blindingly obvious. I'm sorry, but it's not obvious to me. Clearly you're aware of a situation in which a selective expand-all action that appears on a context menu would be more efficient than the new auto-expand behavior. Perhaps you encounter that situation all the time. In such a situation it would be natural to assume that everyone else must always encounter it as well, but since I don't encounter it it won't be obvious to me until you explain it. In comment 16 I tried counting the mouse clicks to reach and open 5 search results in a search of .java files, and found that auto-expand would match a context menu action that expands the selected subtree. In comment 18 and comment 24 described a use-case for doing expand-all on the entire tree (not just the selection), which is covered by the toolbar action and does not necessitate a context menu action. Comment 24 mentions a problem of discoverability of the toolbar button, which is a legitimate concern. I'd suggest we file a separate bug to track that. Discoverability could be addressed by adding "Expand All" to the view menu, which would be better than the context menu since it would eliminate the expectation that it acts on the selected item. I actually agree with Lars' comments in bug 477471 - context menu actions are expected to act on the selected item, not the entire tree... but that doesn't mean we shouldn't have an "Expand All" action somewhere that's easy to use and easy to find. Here's a suggestion: We could add an unbound command handler so that users who use the command all the time can access it more efficiently from a keybinding... and we could add the action to the view menu so that folks that aren't aware of the toolbar item or keybinding can discover it. That would address both the discoverability concern from comment 24 and the efficiency concern from bug 477471, comment 14 while still preserving Lars' desire to reserve context menus for actions that affect the selected item. I've extracted bug 503155 for the remaining work (toolbar hard to discover and inefficient to activate), and offered my suggestion from comment 27 as a potential fix. Additional comment on my use case in comment #24: I still try to click that expand all context menu item every time I run a search even though I've known it hasn't been there for months. Muscle memory, I guess. A better feature that fits my use case might be to add to preferences an option to expand all search results by default when a search occurs. > A better feature that fits my use case might be to add to preferences
> an option to expand all search results by default when a search occurs
We could, but there's performance problems in the SWT tree widget that could cause serious (multi-minute) UI freezes with such an option and it's unlikely that users who select the option would understand that this is what they're opting into. Even if they did, they probably wouldn't understand that the particular UI freeze they experienced was connected with an option they enabled days or weeks before.
Another alternative might be to switch the search view from using a standard tree widget to using a custom tree that is completely lazy and virtual - one that performs well regardless of the size, shape, and expansion state of the tree. If we were to do that then we could just show search results fully expanded by default for everyone, unconditionally.
We could also consider using a table rather than a tree (with one row per result) - there's some very good community-written custom table widgets that we could promote to be part of platform. That would address the performance issues and do away with the notion of expanding search results entirely.
|
Created attachment 263253 [details] Eclipse Mars 2 Search View Context Menu Expand All Someone seems to have removed the "Expand All" Menu Item from the Search View Context Menu in Neon. This is a much needed feature. Its absence causes massive click sessions. Please reinstate.