Customize layout from settings

[fcollonval]

References

Fix #8960

Code changes

User-facing changes

Backwards-incompatible changes

[jupyterlab-probot]

Thanks for making a pull request to jupyterlab!
To try out this branch on binder, follow this link:

[fcollonval]

cc @jtpio @ellisonbg @bollwyvl here is a proposition to get widget layout customization. I think we could use such approach in RetroLab too to overcome supporting extension panel positionning in it. For example, in retrolab we could allow three state for sidebar: left, right, treeView (depending if the panel needs to be positioned on a notebook sidebar or in the initial tree view).

For now the key looked for in the settings is either the factory name or the widget id (for singleton panel). If I propagate the use of the new generic SidePanel, this could even be used to do something like inserting the running panel within filebrowser sidebar.

[bollwyvl]

fascinating, will take a look!

[bollwyvl]

One thought on this: at the end of it, I would hope there wouldn't be much "special" stuff that was not introspectable from outside that couldn't be resolved until there was a JS interpreter and hot DOM.

By that I mean: instead of the magic string terminals it might be something namespaced by @jupyterlab/terminals, as one of the more (accidentally) powerful patterns we have is that @{org}/{pkg}:{plugin} is configurable if and only if there exists a file called $PREFIX/labextensions/${org}/${pkg}/{schemaDir}/{plugin}.json (ignoring for the moment that you have to look up schemaDir). There, schema has also given us predictable human-readable things to know, as well as lots of configuration.

A less-discoverable language we already have is lumino commands. This is also, semi-accidentally, surfaced by the workspace. It suffers, however, from the commands not being registered by a controlled namespace.

I imagine the final form of this at some point in the future being an abstract data shell that is a mapping of (the possibility of a) components to a set of regions, with a descriptive-enough language that it would be straightforward to build a visual tool that could discover, configure, and re-combine all available screen elements into:

• a dashboard
• a single-cell
• a presentation

...where any of them could include self-modifying tools, such as a command palette (with the now-hidden group metadata restored, and expanded).

Practically, I imagine this would change shell.add to not specify (or at least require/always respect) area, as the user-configured shell would decide, based on the widget type, where that-which-is-being-added should go, especially if the chosen area didn't exist.

also cc @ajbozarth... this isn't exactly the launcher issue (never made the issue, sorry), but it's a related concern, as launchers would probably have to be aware of this kind of system.

[trungleduc]

Thanks @fcollonval, minor suggestions on the doc then it looks great to me!

[fcollonval]

Thanks @trungleduc for the review

[jtpio]

Nice this is looking good 👍

Just tested on Binder and it looks like the terminal is still opened in main area when created from the launcher:

terminal-open-right.mp4

[fcollonval]

Good catch @jtpio - I updated the launcher card click callback to only move the widget (and close the launcher) if the widget is added to the main area.

[jtpio]

Nice thanks!

Apart from that it's looking good. I think we can get this in so it can be released in the next 4.0 pre-release and tested in Notebook v7.

[jtpio]

Check again on Binder and looking good:

terminal-open-right-launcher.mp4

[jtpio]

Thanks!

[fcollonval]

Thanks for the reviews

[github-actions]

Benchmark report

The execution time (in milliseconds) are grouped by test file, test type and browser.
For each case, the following values are computed: min <- [1st quartile - median - 3rd quartile] -> max.

The mean relative comparison is computed with 95% confidence.

Results table

Test file	large_code_notebook	large_md_notebook
open
chromium
actual	20951 <- [22841 - 23296 - 23631] -> 24677	3906 <- [4175 - 4238 - 4322] -> 4551
expected	19364 <- [21841 - 22526 - 23195] -> 23749	3771 <- [3912 - 3963 - 4043] -> 4406
Mean relative change	3.8% ± 1.1%	6.2% ± 0.9%
switch-from
chromium
actual	633 <- [734 - 756 - 769] -> 819	531 <- [575 - 588 - 608] -> 719
expected	645 <- [713 - 732 - 751] -> 849	516 <- [545 - 557 - 570] -> 633
Mean relative change	2.4% ± 1.2%	6.3% ± 1.3%
switch-to
chromium
actual	398 <- [432 - 461 - 471] -> 551	761 <- [793 - 806 - 824] -> 902
expected	384 <- [429 - 455 - 465] -> 526	252 <- [757 - 770 - 785] -> 840
Mean relative change	1.6% ± 1.7%	5.8% ± 1.7%
close
chromium
actual	587 <- [1058 - 1095 - 1123] -> 1260	577 <- [615 - 630 - 645] -> 705
expected	586 <- [1068 - 1128 - 1169] -> 1463	561 <- [588 - 595 - 606] -> 644
Mean relative change	-6.8% ± 4.3%	5.5% ± 1.0%

Changes are computed with expected as reference.