Add API support for file decorators, custom classes and extra columns

[krassowski]

Following on the discussion on future adoption of tree-finder in JupyterLab, I wanted to bring up some use-cases that are not accommodated by the current file browser, but would be great to have in the bright future with tree-finder.

As discussed in jupyterlab/jupyterlab-git#124 (comment) jupyterlab-git would like to be able to add custom indicators for the files to highlight which files were modified, added, deleted or are ignored. The idea is to implement it as both:

• an extra icon to the right or left of the filename (as in VSCode)
• a text colour modification (as in PyCharm)

and let user choose which one to use. The text color modification would modify the filename display, so possibly could be implemented by allowing to update the classList of the file item. The extra icon could be implemented using a special column (it makes sense to sort by the git status).

An initial work using the current JupyterLab filebrowser was done on jupyterlab/jupyterlab-git#885:

but it was a bit hackish and would not work if multiple extensions wanted to modify the filebrowser items.

Another briefly explored idea was to add icon modifier:

This does not seem optimal for this use case, but might be handy for other uses.

It would be useful to make it available for both files and folder, and maybe even the breadcrumbs section, to accommodated designs by @weihwang such as jupyterlab/jupyterlab-git#124 (comment):

Finally, it was proposed that it might be handy for multiple extensions to add custom decorators for files, as in an example brought up by @fcollonval over at jupyterlab/jupyterlab-git#885 (comment):

This one comes from VSCode and shows both a number of diagnostic warnings (e.g. linter errors) and the git status. This would mean that both the LSP extension and the git extension would need to simultaneously be able to modify the file items.

Finally, it would be great to have a working mechanism for toggling these columns.

To summarise I would like to request (and help in implementing) a public API for following functionalities:

• add/remove class for file/directory item
  • if file icon is a separate element, then also add/remove class for file icon (to allow to add modifiers with CSS)
• add/remove column for the browser
• add/remove non-column decorator (this is distinct from a custom column in the way that it does not take a full column of width/space, and distinct from simple custom class in that it allows for more complex decoration and can be used for important information that would not meet accessibility criteria if only presented using a CSS class) for file/directory item
• add/remove indicator for the breadcrumbs

Would all of the above be in scope for tree-finder? Is it possibly already capable of the above?

[telamonian]

@krassowski tree-finder currently supports all of the things in your list in one form or another. There's probably some conceptual gaps, and there's no nice api for a lot of it, but all of those things are supported.

if file icon is a separate element, then also add/remove class for file icon (to allow to add modifiers with CSS)

I haven't really decided yet how to handle file icons. This will hopefully become clearer as the tree-finder/jupyterlab integration matures. In the meantime, you can use the addStyleListener method of the <tree-finder-grid> element (which inherits the linked code from regular-table and the <regular-table> element) to do pretty much whatever you want to each row of the table, including adding/removing classes.

add/remove non-column decorator

tree-finder (and regular-table below it) don't really distinguish between different kinds of columns, you can even pass in actual live DOM nodes as your column data and tree-finder will just render them. The width of each column is simply the minimum space require to display the contents.

The only thing I can think of that would cause trouble for an "annotation" column is that currently all columns require a name, which gets displayed in the column header. So internally the annotation column would still have a name, and then we could use some styling tweaks to prevent display