👈 Launch a binder notebook on branch krassowski/jupyterlab-git/colour-files-in-browser

Ready for feedback. I listed two known issues which would be nice to get feedback on. The third issue is getting the setters exposed in JupyterLab. I will submit PR if you agree that this is a good approach for now (by now I mean JupyterLab 3.x).

@telamonian, is your new file browser on roadmap for JupyterLab 4.0, or more like 5.0?

While this PR does not add another column with an icon to the right, it would be easily possible by:

• appending another span element to the node in updateItemNode of listing renderer, and
• appending another div element to the node in populateHeaderNode of listing renderer

So we could implement the design from #124 fully using this approach (in particular the right-most panel of #124 (comment)). I am not full convinced on the utility of such design - colors work for me well enough, but if there is a consensus that another column should be added in addition to the colors I would be happy to tackle this (we could make it customizable with showStatusColor: boolean, showStatusColumn: boolean)

Alternatively, the file icons could get an overlay by simply adding a CSS style like

    '.jp-DirListing-itemIcon::after': {
      content: '"A"',
      position: 'absolute',
      top: '6px',
      left: '10px',
      background: 'rgba(255,255,255,0.7)',
      display: 'block',
      width: '11px',
      height: '16px',
      fontSize: '11px'
    }

It would look crammed to me though...

I implemented the @weihwang's indicator design from #124 (comment) and added settings so either the indicator, coloring or both can be disabled/enabled.

I would really appreciate an early feedback on whether you want to go this path (i.e. I should open a PR in JupyterLab to expose the renderer), or not.

Thanks @krassowski This is awesome work.

The design of #124 is certainly heavily inspired by VS Code. A reason for adding a DOM element with the file status may be accessibility (this is purely a guess) - coloring being probably though to translate for screenreader.

The trouble at JupyterLab level is indeed if multiple extensions want to apply a custom styles.

In VS Code they use the additional columns to concatenate the information. For example in the screenshot below, the 4 states that there are 4 warnings and M that the file is modified - according to git. The style are ranked as can be seen on index.ts that appears in red because 9 errors are detected and not in yellow because it is modified.

As I'm using VS Code daily. So my opinion is biased towards having a indicator in addition of the color 😁 But I agree with you stacking it with the file type icon is not easy to ready. And I found the @weihwang's indicator a bit to eye catchy. I prefer the more discrete approach of VS Code of a single colored letter.

Regarding ignored files, it won't be easy. We should list them as much as possible. So the best approach seems to focus on testing only the files displayed in the file browser.

I dig into VS Code logic. They are using the command git check-ignore -v -z --stdin. And it is called when the file browser is refresh and when a folder is expanded in the tree view (I don't have access to the input provided).

Adding setting to tune the look and feel is really a great addition

In VS Code they use the additional columns to concatenate the information. For example in the screenshot below, the 4 states that there are 4 warnings and M that the file is modified - according to git. The style are ranked as can be seen on index.ts that appears in red because 9 errors are detected and not in yellow because it is modified.

PyCharm on the other hand uses only colors to indicate git status (no letter indicators).

The trouble at JupyterLab level is indeed if multiple extensions want to apply a custom styles.

I'm also hitting the limits of the current Renderer pattern in the LSP extension when it comes to comlpeter. It feels like hooks could be easily implemented using lumino.Signal (e.g. file browser emits listingItemRendered: Signal<FileBrowser, HTMLSpanElement> and listeners are free to add whatever they want), though I am not sure what would be the performance implications. We could test it by force-swapping renderer and implementing this here before upstreaming in JupyterLab.

I am not sure what would be the performance implications.

Yes this is gonna be definitely a point to monitor. Especially if there are lots of items - it may require implementing windowing the listing view.

We could test it by force-swapping renderer and implementing this here before upstreaming in JupyterLab.

Definitely worth experimenting and this extension offers a good opportunity. @ianhi did some testing on the changed files list in #667 (comment). It may be a source of inspiration to challenge the JupyterLab file browser with such signal. It is certainly a good subject to bring at the JupyterLab developer meeting to.

@all-contributors please add @krassowski for code, review and bug

@fcollonval

I've put up a pull request to add @krassowski! 🎉