Preview tab

[fcollonval]

Problem

Having lots of tabs opened simultaneously is famous to hit hard performance in JupyterLab. It bottles down to having lots of nodes in the webpage. So any trick that can reduce the number of nodes (like the windowed notebook) is beneficial.

This makes me consider differently the preview tab feature implemented by VS Code. I'm convinced that one of the purpose is to cheaply reduce the number of nodes/documents.

Proposed Solution

In jupyterlab-git, a prototype was implemented for the diff views in jupyterlab/jupyterlab-git#1184 (quiet hacky actually).

I would love to see it lands in Lumino 2 / Lab 4.

Additional context

[welcome]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.

You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

[fcollonval]

@krassowski What do you think about this idea?

[krassowski]

Looking at the jupyterlab-git PR:

• we should make adding admonitions to tab widgets easier in lumino, the code for that is hacky
• the optionally singleton MainAreaWidget subclass could be added to JupyterLab or lumino; it seems that the git extension PR extends MainAreaWidget from @jupyterlab/apputils, so maybe this is the place where such a sublcass should be defined (rather than lumino)?

[fcollonval]

Thanks @krassowski

we should make adding admonitions to tab widgets easier in lumino, the code for that is hacky

Definitely, being to get access to tab related widget would be benefitial.

the optionally singleton MainAreaWidget subclass could be added to JupyterLab or lumino

This is the area I'm uncertain. If we promote the path used in jupyterlab-git, it means that not all tabs within a given tab/dock panel will get the feature and developer of each extensions will need to add support for it. So I was wondering if we should not make it part of TabPanel/DockPanel directly (through an configurable option) to have a more consistent user experience.

We could for example add a new attribute on Title. So defining or changing the preview status will be as easy as widget.title.preview = true || false;. The panel will look at all the titles to see if there is one in preview to determine what to do when one new tab is inserted.
The TabPanel.IOptions would also gain an option hasPreview : boolean that activates or not that behavior.

[krassowski]

Just a minor comment: not a fan of modifying behaviour by setters of widget.title. It feels like this should be a separate attribute, or maybe an .options to gather them.

[fcollonval]

Just a minor comment: not a fan of modifying behaviour by setters of widget.title. It feels like this should be a separate attribute, or maybe an .options to gather them.

There is a precedent with closable:

lumino/packages/widgets/src/title.ts

Lines 249 to 255 in abfd491

	set closable(value: boolean) {
	if (this._closable === value) {
	return;
	}
	this._closable = value;
	this._changed.emit(undefined);
	}