Extension: Removing/reordering Launcher categories

I am attempting to customise the Launcher for a JupyterLab session for students, specifically by arranging important links at the top of the launcher. However, category order seems to be hard-coded using KNOWN_CATEGORIES = [‘Notebook’, ‘Console’, ‘Other’], so any items I add either need to be in or below these categories.

Is there a simple way to override KNOWN_CATEGORIES and/or remove the other items in the Notebook category without creating an entire separate custom Launcher extension, as suggested here or here?

1 Like

Short answer is no, there isn’t a simple way to override those categories. It looks like those categories are hardcoded in the existing Launcher, so either a PR to the existing launcher to make it more configurable, or replacing the core Launcher with your own, seem like the natural options for moving forward.

Can you please show me an example, how to replace a core extension?
One of my concern is that the ILauncher interface will not be available when I disable the core launcher.
And even if I extend this interface, and create my own launcher, the other extensions which register themselfs with the core launcher, how can they find my replacement extension.

If you implement ILauncher (exactly one method, add), and return an instance of that from your plugin’s activate function, your extension will receive all of the calls that would have gone to the core implementation. I actually don’t have a concrete example of doing so, but you kinda just start solving the typescript puzzle (either in an editor that supports typescript, or with the tsc -w running).

A few singletons (e.g. the app’s CommandRegistry and ServiceManager) don’t work this way, but pretty much everything else does.

The term of art here is dependency injection. Other frameworks like AngularJS or Sprotty take this maybe a little too far, but have their reasons for doing so (fully integrated test tools, parity with Java tooling, etc). I personally find the Lumino level pretty useful for organizing applications without making piles of ImplementationFactoryActualizationMethodCallers (though to be fair, ABCWidgetFactory you have to build for Documents basically sounds just as made up until you dig into it).

1 Like