Add breadcrumbs for editors

[colin-grant-work]

This PR updates #6371 and completes the remaining to-do's from that PR.
Closes #6371

From that description:

This commit adds a breadcrumbs bar to the editor widget. It shows the path to the current file and outline information as breadcrumbs. A click of breadcrumbs allows to switch to siblings.

This fixes #5475.

How to test:
Open an editor shows the breadcrumbs on top of the editor. Folders with files are clickable. A popup allows to select a file that will be opened immediately. Outline information is added to the breadcrumbs as well.

A few more details:

1. You should see breadcrumbs for NavigatableWidgets (mainly editors) that are docked in an area with a horizontal tabbar. Those breadcrumbs should contain at least the path to the file.
2. For editors with language support, you should get the content of the outline view for the location of your cursor.

Try refreshing when you have a TS file open. The layout should be restored. There were changes to the Outline view that required changes to its state restoration.

3. If you open a non-navigatable widget, the breadcrumbs bar should disappear.
4. There is a preference to disable breadcrumbs. If you disable the breadcrumbs, they should disappear, and they shouldn't reappear anywhere.

Watch out for any odd styling behavior in the transition from breadcrumbs <-> no breadcrumbs. I think I've handled it, but there may still be some quirks.

5. If you click a breadcrumb, it should open a popup. The popup should show other possibilities at the same level of organization (sibling folders, object fields, etc.).
6. You should be able to navigate the tree

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

[kenneth-marut-work]

Looks really nice so far, and really nice functionality. Things mostly seem to be behaving as expecting but I have a few observations after doing an initial feature test:

---

• Toggling the preference to show hide doesn't seem to resize the base editor, so you get a empty bar:

After waiting several minutes, I was able to get the correct behavior, but it seems to be very finicky. For example in in this GIF, you'll see the breadcrumbs toggle ON, but when I click on the editor they disappear again:

---

• In VSCode, clicking on a path segment reveals the corresponding segment (and selected) and its siblings at the top level vs. in this PR, we see the path segment's parent at the top level (and the segment is unselected):

VSCode

This PR

---

The treeview seems to have a minimum height that looks a bit odd when there are not enough elements to populate the view. In VSCode the view seems to only take up the minimum height it needs (and changes height when nodes are expanded -- up to a fixed maximum height):

---

Very minor: the breadcrumbs is a 24px height but the viewContainer toolbar is 22px. In VSCode they are both 22px (I only noticed it via the broken toggle mentioned above 🙂)

---

In VSCode, if I click on a path segment in the breadcrumbs and then click on a file inside that crumb, a new editor opens with that file in preview mode. In this PR, the file opens in normal editor mode.

This PR

VSCode

[colin-grant-work]

@kenneth-marut-work, thanks for taking a look. I believe I've addressed your comments.

• the odd toggling was a consequence of not hooking into Phosphor's fit logic; I've added code that asks the tabbar's parent to fit everything to size.
• added code that selects the node corresponding to the crumb clicked on.
• changed the trees to non-virtualized so that they can have a definite height smaller than 200px if there's less content to render.
• changed the height of the breadcrumbs area to 22px. You'll have to check in your fancy theme whether everything lines up now :-)
• changed the opener to use {preview: true}

[msujew]

I managed to notice some weird behavior as well. When opening the file tree via the breadcrumbs and opening a folder in there, clicking outside of the popup does not close the popup. This leads to things like these:

[colin-grant-work]

I managed to notice some weird behavior as well. When opening the file tree via the breadcrumbs and opening a folder in there, clicking outside of the popup does not close the popup.

@msujew, thanks for pointing this out. It pointed the way to some overly elaborate focus handling logic that conflicted with the expectations of the widgets being rendered in the popups. I've simplified that and used focusout events rather than blur to make things a little more flexible.

[kenneth-marut-work]

A couple minor comments, also as we discussed offline the WorkspaceBreadcrumbsContribution doesn't seem to be doing what it should (prefixing the breadcrumbs with WS name in multiroot). But otherwise the functionality is very impressive and is working great for me, and thanks for addressing my previous comments as well 👍

[kenneth-marut-work]

Looks good to me, thanks for the fix! Nice work 🍞

[vince-fugnitto]

@colin-grant-work do you mind rebasing the pull-request, I'll take some time to review so we can have it for 1.18.0 :)

[msujew]

Looks good to me, great work 👍

One minor nitpick: vscode uses a larger padding on the left side, which I think looks a bit nicer:

vscode:

Theia:

[vince-fugnitto]

I noticed the perfect-scrollbar styling might be off for the breadcrumbs compared to the rest of the application (and vscode).
I'm not sure if it is something we want handled initially by the pull-request but I was able to reproduce on electron:

scrollbar-electron.mp4

[colin-grant-work]

I noticed the perfect-scrollbar styling might be off for the breadcrumbs compared to the rest of the application (and vscode).
I'm not sure if it is something we want handled initially by the pull-request but I was able to reproduce on electron:

@vince-fugnitto The easiest (and, I think, most correct) way to solve that would be to remove the scroll bar from the breadcrumb popup container and require breacrumb providers to provide their own scroll if necessary - both of the current ones show tree widgets, so they come with their own scrollbars anyway. That also avoids duplication of scroll bars in case the rendered UI happens to include a scroll bar, as all widgets would. Does that sound reasonable?

[vince-fugnitto]

@vince-fugnitto The easiest (and, I think, most correct) way to solve that would be to remove the scroll bar from the breadcrumb popup container and require breacrumb providers to provide their own scroll if necessary - both of the current ones show tree widgets, so they come with their own scrollbars anyway. That also avoids duplication of scroll bars in case the rendered UI happens to include a scroll bar, as all widgets would. Does that sound reasonable?

I think that sounds reasonable yes :)

[colin-grant-work]

@vince-fugnitto The easiest (and, I think, most correct) way to solve that would be to remove the scroll bar from the breadcrumb popup container and require breacrumb providers to provide their own scroll if necessary - both of the current ones show tree widgets, so they come with their own scrollbars anyway. That also avoids duplication of scroll bars in case the rendered UI happens to include a scroll bar, as all widgets would. Does that sound reasonable?

Turns out I couldn't do that. I'd hoped the good styles were attached to widgets, but in fact they're attached to the shell, and dialogues, and now also breadcrumb popups. I think we could do that better, since I think we really just mean 'everywhere in the application,' but someone decided that that should be classed down to the shell. If you agree, @vince-fugnitto, we can probably simplify the perfect scrollbar CSS section by eliminating all of the #-referencing prefixes, but that might have unintended consequences (maybe the monaco overlays use PS and want different styles, e.g.? Perhaps best to put that off for another PR.

[colin-grant-work]

If CI passes and no one objects, I'll merge this Wednesday or Thursday.