[WIP] Add colours for files in file browser

[krassowski]

Further exploring the proof-of-concept from jupyterlab/jupyterlab#5499 (comment).

Can fix #124 (the issue was open for a long time, it would be nice to resolve it for users who need it here and now).

To compare changes without the Git context menu: krassowski/jupyterlab-git@add-browser-context-menu...krassowski:colour-files-in-browser

Demo GIF:

Instructions for easy testing on binder

To test on binder open console and paste

echo "*.ignored" >> ".gitignore"
mkdir test
cd test
echo "added" > added-file
echo "modified" > modified-file
echo "removed" > removed-file
echo "unstaged" > unstaged-file
echo "ignored" > file.ignored
git add modified-file removed-file
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git commit -m test
git add added-file
git rm --cached removed-file
echo "modification" >> modified-file
echo "Done; refresh the git status in GitPanel and then open FileBrowser (navigate to test directory)"

If in need, consult:

To avoid the requirement of using a manual action to refresh the status (triggering context menu, or visiting the GitPanel) I connected signals that:

• trigger file browser refresh after each git status update, and/or,
• trigger initial status refresh after entering a git repository

Known issues:

1. Ignored files are not styled; this is because the ignored files are not a part of the model status.files: IStatusFile[] property. The refreshStatus() method uses the status endpoint which does not return ignored files (which might be good for performance).
   • is it worth to transfer all the ignored files just to be able to highlight them in the file browser (performance, vs utility trade-off)?

[github-actions]

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

[krassowski]

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?

[krassowski]

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...

[krassowski]

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.

[fcollonval]

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

[krassowski]

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.

[fcollonval]

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.

[fcollonval]

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

[allcontributors]

@fcollonval

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