Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[tree][navigator]Tree search #1479

Closed
13 tasks done
kittaakos opened this issue Mar 12, 2018 · 28 comments
Closed
13 tasks done

[tree][navigator]Tree search #1479

kittaakos opened this issue Mar 12, 2018 · 28 comments
Assignees

Comments

@kittaakos
Copy link
Contributor

kittaakos commented Mar 12, 2018

Must:

  • It should be possible to quickly navigate to an expanded node using fuzzy text search.
  • Occurrences in matching and already expanded nodes should be highlighted.
  • It should be activated whenever a user starts typing in a focused tree widget.
  • It should not take invisible nodes into account.

Also:

  • Investigate other IDEs. WebStorm, Eclipse, etc.
  • Maybe, a search box should be overlayed while typing the search term.
    • When do we hide this search box.
    • What should be the delay, if any before executing the filter and typing.
    • Can the user continue the filtering? For instance type exp -> then continue lor -> Then, do we search for lor or explor.
    • Do we hide it on Esc?
  • Can we reuse the decorators for that?
  • Does it make sense to support it to all tree widgets in general?

Update:
Make sure, the following issues are also resolved as part of this task.

Update2:
Q: Does it make sense to support it to all tree widgets in general?
A: It is possible. If we need it we can do this later.

@kittaakos kittaakos self-assigned this Mar 12, 2018
@akosyakov
Copy link
Member

I've seen this feature only in IntelliJ and like how it works there.

@kittaakos
Copy link
Contributor Author

Did not try it in IntelliJ, isn't it the same as in WebStorm? If no, I will try IntelliJ too. By the way, we are trying to mimic that behavior for sure.

@akosyakov
Copy link
Member

Yes, it is the same.

@kittaakos
Copy link
Contributor Author

Eclipse:

  • Jumps to the next node that matches the pattern.
  • No highlighting.
  • No way to navigate back to previous matches.

WebStorm does the following:

  • After a successful search (and some delay), they jump to the first match.
  • They hide the search widget when one starts navigating with the cursor keys.
  • Cursor navigation => jumps only to selected nodes.
  • Where there are no matches, they leave it on the UI. One can close it with Esc.

I think the WebStorm approach is a good initial pattern to mimic.

screencast 2018-03-13 09-07-03

@akosyakov
Copy link
Member

How do they navigate between matches?

@kittaakos
Copy link
Contributor Author

With the Up and Down cursor keys.

@svenefftinge
Copy link
Contributor

I think the WebStorm approach is a good initial pattern to mimic.

+1 it feels nice and simple.

@kittaakos
Copy link
Contributor Author

I just do not know yet, where to overlay the widget for the search term. Any suggestions?

kittaakos added a commit that referenced this issue Mar 14, 2018
@kittaakos
Copy link
Contributor Author

Depends on #1450. I cannot traverse the tree unless I can use the fixed tree iterators.

@kittaakos
Copy link
Contributor Author

I just do not know yet, where to overlay the widget for the search term. Any suggestions?

CC: @AlexTugarev

I am open to any ideas about the search box and its position. We have this so far, but this can be improved for sure:
gh-1479

kittaakos added a commit that referenced this issue Mar 14, 2018
@AlexTugarev
Copy link
Contributor

What about increasing the contrast of this overlay? Maybe add a drop shadow to indicate overlay, as I assume it should stay fixed while scrolling.

Another option could be to place is half outside the top border, which would keep the functionality of the main menu. The position on the left hand side would keep the "Search for:" prefix at a fixed position. Shifting that prefix back and forth seems a bit noisy.

screen shot 2018-03-14 at 20 39 58

@lmcbout
Copy link
Contributor

lmcbout commented Mar 14, 2018

AS Alex mentioned, I find it noisy when you type and see the text moving to the left. I think having it on the left side and half way as Alex mentioned seems a good place to be

@kittaakos
Copy link
Contributor Author

@AlexTugarev, @lmcbout, thanks for the feedback.

Shifting that prefix back and forth seems a bit noisy.

Sorry for the confusion, I would go with a minimum width, then it could grow. The probability you would like to search for more than 8-10 characters is quite low.

Maybe add a drop shadow to indicate overlay, as I assume it should stay fixed while scrolling.

I like this.

Another option could be to place is half outside the top border

That is good unless you move the navigator to the right, or to the bottom, etc. I have no objections against moving this outside but +1 for keeping this inside. Otherwise, it would look alien compared to other UI elements, isn't it?

increasing the contrast

Initially, I liked the idea. Now I would say; it's too much.

@AlexTugarev
Copy link
Contributor

I would go with a minimum width, then it could grow. The probability you would like to search for more than 8-10 characters is quite low.

sounds good, if it starts with a width which doesn't need to be increased for ~10 chars.

one more option:
2018-03-14 21 41 21

@kittaakos
Copy link
Contributor Author

That is nice; I am not sure if we want to show the hit count.

@AlexTugarev
Copy link
Contributor

It was more about the drop down effect.

@kittaakos
Copy link
Contributor Author

Yeah, I got it. There is one problem with drop-down effect; when you do this in the browser (I assume, you got the idea from there), you trigger the search with Ctrl/Cmd+F. In our case it should instantly filter whenever you type something, so we cannot have that delay. It should be way faster.

@kittaakos
Copy link
Contributor Author

We have this so far; I have overlayed the root node:
screencast 2018-03-15 17-32-40

@lmcbout
Copy link
Contributor

lmcbout commented Mar 15, 2018

Another suggestion,
If you do a search (CTRL+ F ) in Firefox, it open a dialog over the status bar at the bottom with some extra search options, (Highligh All, Match Case, Whole Worlds) , should we implement something similar !

@kittaakos
Copy link
Contributor Author

Not in the context of this task. Please reference the Must list in the task description. But feel free to open a follow-up.

@kittaakos
Copy link
Contributor Author

Depends on #1517.

kittaakos added a commit that referenced this issue Mar 15, 2018
kittaakos added a commit that referenced this issue Mar 15, 2018
Closes #1479.
Closes #1493.

Signed-off-by: Akos Kitta <[email protected]>
kittaakos added a commit that referenced this issue Mar 16, 2018
kittaakos added a commit that referenced this issue Mar 16, 2018
kittaakos added a commit that referenced this issue Mar 16, 2018
kittaakos added a commit that referenced this issue Mar 16, 2018
@akosyakov
Copy link
Member

I like it without icons and outside otherwise the navigator looks stuffy and one cannot see all files. IntelliJ also allows drag and drop views to sidebars and they keep the search just above always. I know that it will overlay the menu in our case, but it should be fine since one wants to find something in the navigator not to use menus. Could we try it like that?

@akosyakov
Copy link
Member

Regarding style cannot it be aligned with the quick search widget?

@kittaakos
Copy link
Contributor Author

Regarding style cannot it be aligned with the quick search widget?

Let's try that.

cannot see all files.

Exactly one file is overlayed.

Could we try it like that?

I do not like that approach but we can try. If it is easy you can decide which one to have. +1 to have it inside.

@kittaakos
Copy link
Contributor Author

Or we can go back to the initial idea and have it after the root node with a min length of 10. So it will not overlay tree nodes still remains inside.

@kittaakos
Copy link
Contributor Author

quick search widget?

@akosyakov What styles you mean? I cannot find anything special.

kittaakos added a commit that referenced this issue Mar 16, 2018
@kittaakos
Copy link
Contributor Author

If you meant setting the font weight to bold, that is so bad. I have not even noticed it so far :)

@akosyakov
Copy link
Member

I meant if a search box is the overlay widget similar to the quick command widget it would be nice if they look alike. I did not mean any concrete styles.

kittaakos added a commit that referenced this issue Mar 16, 2018
Also reused disposables from the parent widget.

Signed-off-by: Akos Kitta <[email protected]>
kittaakos added a commit that referenced this issue Mar 16, 2018
kittaakos added a commit that referenced this issue Mar 19, 2018
kittaakos added a commit that referenced this issue Mar 19, 2018
kittaakos added a commit that referenced this issue Mar 19, 2018
bhufmann pushed a commit to bhufmann/theia that referenced this issue Jul 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants