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

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.

fascinating, will take a look!

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.

Thanks @trungleduc for the review

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:

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.

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.

Check again on Binder and looking good:

Thanks for the reviews

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.