any approach to override icon/renderer for specific folder?

[linlol]

Problem

We are working on an internal jupyter lab solution. In this solution, there is some folder managed by ourselves (for example, a folder controlled by git records common util notebooks)

Is there any approach to specify another piece of svg string to notebooks with special name pattern?

This could also be a common requirement I guess? Suppose the case that give node_modules a dedicated icon

Proposed Solution

One possible solution is leave an abstraction like fileType, which enables application maintainer to customise it in lab extension

With such kind of abstraction, it shall also be better if we can make it configurable in setting registry

Additional context

[krassowski]

This is already possible. You can register a custom file type (IFileType) on the document registry and provide a custom icon. You can do it directly by calling DocumentRegistry.addFileType which would be likely the best approach for you, or via a MIME extension see this example. Note that either way you would provide an empty list for extensions argument and set the optional IFileType.pattern, e.g. to ^node_modules$.

[linlol]

thanks @krassowski !

Yes I found this yeaterday and blocked by the mimetype setting.

Would have a try base on your example, thanks a lot!

[linlol]

Hi @krassowski

I have a try as below and somehow it doesn't work even though I can see my customised views registered in document manager

This is what I tried (I am sorry that I cannot share screenshot/source code of internal project)

1. Setup regular extension typed as jupyterfrontendplugin with addfiletype logic called in activate function

2. Create customised fileType from DocumentRegistry.getDefaultDirectoryFileType function, and override name/display name as dummy, customise pattern as "^node_modules$", icon customised as ui-components/JuliaIcon as example

3. get DocumentRegistry instance from global jupyerFrontEnd instance and call docRegistry.addFileType

After above operations, I can see my customised fileType registered in setting editor, but icon still not changed. Maybe it is overriden by default directory rule, is there anything like rank?

[krassowski]

Directories and notebooks are treated specially:

jupyterlab/packages/docregistry/src/registry.ts

Lines 664 to 692 in 82051a9

	getFileTypeForModel(
	model: Partial<Contents.IModel>
	): DocumentRegistry.IFileType {
	switch (model.type) {
	case 'directory':
	return (
	find(this._fileTypes, ft => ft.contentType === 'directory') ||
	DocumentRegistry.getDefaultDirectoryFileType(this.translator)
	);
	case 'notebook':
	return (
	find(this._fileTypes, ft => ft.contentType === 'notebook') ||
	DocumentRegistry.getDefaultNotebookFileType(this.translator)
	);
	default:
	// Find the best matching extension.
	if (model.name || model.path) {
	const name = model.name || PathExt.basename(model.path!);
	const fts = this.getFileTypesForPath(name);
	if (fts.length > 0) {
	return fts[0];
	}
	}
	return (
	this.getFileType('text') ||
	DocumentRegistry.getDefaultTextFileType(this.translator)
	);
	}
	}

Maybe we need to make a small change in the docregistry code? Would you be open to submitting a pull request?

[linlol]

Directories and notebooks are treated specially:

jupyterlab/packages/docregistry/src/registry.ts

Lines 664 to 692 in 82051a9

	getFileTypeForModel(
	model: Partial<Contents.IModel>
	): DocumentRegistry.IFileType {
	switch (model.type) {
	case 'directory':
	return (
	find(this._fileTypes, ft => ft.contentType === 'directory') ||
	DocumentRegistry.getDefaultDirectoryFileType(this.translator)
	);
	case 'notebook':
	return (
	find(this._fileTypes, ft => ft.contentType === 'notebook') ||
	DocumentRegistry.getDefaultNotebookFileType(this.translator)
	);
	default:
	// Find the best matching extension.
	if (model.name || model.path) {
	const name = model.name || PathExt.basename(model.path!);
	const fts = this.getFileTypesForPath(name);
	if (fts.length > 0) {
	return fts[0];
	}
	}
	return (
	this.getFileType('text') ||
	DocumentRegistry.getDefaultTextFileType(this.translator)
	);
	}
	}

Maybe we need to make a small change in the docregistry code? Would you be open to submitting a pull request?

Definitely I am happy to but not sure if I am eligible haha.

Maybe let me have a try if nobody else requests this urgently

[linlol]

Just had a full-look, looks like notebook and directory would be forced to default file types such that pattern matching logic would be skipped.

I may propose below logic update

1. For notebook/directory apply fileType by path check via logic like

const tryFts = this.getFileTypesForPath(name)

2. If we get non-null fileType, we check if tryFts.contentType is directory (or notebook respectively)

If so, use user-customised fileType

If not, fallback to the default notebook/directory fileType.

@krassowski please take a glance if it sense to you, if so, I would try to make it this mont

(It would not be that quick as I would not be able to access my personal PC for around 2 weeks due to personal issue)

[JasonWeill]

@linlol Thank you for opening this issue! Which version of JupyterLab are you using?

[linlol]

@linlol Thank you for opening this issue! Which version of JupyterLab are you using?

Hi @JasonWeill , I am currently using 3.6.3

As you can see from the discussion among Krassowski and I, the behaviour shall be indifferent for the latest dev branch

[JasonWeill]

@linlol Thanks for your response. If possible, I recommend upgrading to Lab 4. Most new features are not getting backported to Lab 3.

[linlol]

@linlol Thanks for your response. If possible, I recommend upgrading to Lab 4. Most new features are not getting backported to Lab 3.

@JasonWeill yes, thanks for pointing this, yes definitely we would upgrade jupyter lab 4

[linlol]

@linlol Thanks for your response. If possible, I recommend upgrading to Lab 4. Most new features are not getting backported to Lab 3.

@JasonWeill yes, thanks for pointing this, yes definitely we would upgrade jupyter lab 4

definitely I would not expect this feature onboarding at 3.6.x🤣🤣

[krassowski]

The logic change that you propose appears fine to me - feel welcome to start a PR, from there we can see if this breaks any tests etc. That would be a small behaviour change so I believe we could introduce it in JupyterLab 4.2.0.

[linlol]

thanks, I would start making the change among the end of the month (currently I don't have eligible coding env due to national holiday

[linlol]

hi @krassowski , I make a PR for my change, is there any easy approach to propose a quick test

looks like I need to add enhancement label, can you help add it? (or actually I can do it by myself?)

well nws, I can see a lot of UI integration error... definitely something wrong.

Honestly I don't understand the UI test failure, file type change of directory/notebook shall be irrelevant with the output of cell run

https://github.com/jupyterlab/jupyterlab/actions/runs/7969849144/job/21756346972?pr=15828

is there anywhere to see the snapshot of UI test