Is there a way to change the default “tab” that opens when one opens jupyterlab?
At the moment it defaults to “Launcher”, but I’d like to automatically open my extension when I open jupyterlab.
To open a tab at startup, just create a tab and add it to the main area in your activate function, just like the Launcher does: https://github.com/jupyterlab/jupyterlab/blob/673f96f271717f876788fcfc2e8c107728d3c881/packages/launcher-extension/src/index.ts#L81
If you want the Launcher to not appear, then you’ll need to disable the launcher extension and add your own that removes that line (and the accompanying creation of a widget) from its activate function.
On the other hand, the filebrowser extension is the one responsible for making sure there is always at least one tab open, created with the create:launcher command: https://github.com/jupyterlab/jupyterlab/blob/673f96f271717f876788fcfc2e8c107728d3c881/packages/filebrowser-extension/src/index.ts#L372-L383
Depending on what you want done, perhaps that is the thing to override.
And actually, it may be that if you add your widget to the main area in your activate, the launcher will not appear automatically since the main area will not be empty.
I just realized I misread the launcher code. It creates a command that adds a launcher to the main area. The file browser extension invokes that command if there is no other widget open. So if you add your widget to the main area in your activate function, the file browser will notice there is something already there and will not create a launcher tab by default.
1 Like
Awesome. Thank you @jasongrout. I’ll check it out and let you know how it goes.
@jasongrout I am working with aafshar. I tried adding my extension to the MainAreaWidget inside the extension activate function but this resulted in some strange behaviour. More often than not, on page refresh, the launcher is rendered on the MainAreaWidget. However, every once in a while on page refresh, my extension is rendered onto the MainAreaWidget as intended.
Is this the proper implementation of your description above?
Checking in the browser console, there do not seem to be any relevant error messages.
Yes, that seems okay at first glance. As a next step, I’d probably console.log a message after adding to the shell, make sure that is always displaying, or try stepping through your code to see if you can catch it sometime when it is not working. If your extension is not able to add a widget to the dock area, something seems wrong.
Added a couple console logs before and after adding to the shell. Both console logs are consistently displaying without any errors in between so I’m assuming it was properly added to the shell. However, I’m still getting the inconsistent behaviour described previously. I tried it on a few different browsers (Firefox, Chromium based, Safari) so I’ve ruled out it being a browser-specific issue.
Can you expand on what you mean by stepping through my code? Do you just mean console logs on every line in extension activate()?
I noticed on page refresh, it loads a blank screen on the main area for ~10 seconds, then finally renders the launcher. Checking the console again, I see some fetch errors that should have only executed if my extension is activated.
The fact that I am getting fetch errors from my extension, leads me to believe my extension is being activated, but somehow my extension does not render properly to the MainAreaWidget or the MainAreaWidget does not render to the main area. If my assumption is correct in that the MainAreaWidget does not render properly to the main area, maybe this is why I am getting 10 seconds of blank screen on page refresh. The widget fails to render, then after the ~10 seconds, the file browser notices there is no tab open, and creates a launcher. Assuming this is the issue, do you have any recommendations for how to debug this?
If your widget takes some time to render or load, I’d suggest rendering a loading spinner or some “please wait” text in your widget initially, then asynchronously replacing that with your widget when it is ready. In other words, load a fast placeholder synchronously, then replace later asynchronously when you are ready to show your content.
The issue didn’t seem like it was the length of time my extension takes to render, but rather that the MainAreaWidget doesn’t render at all.
However, to confirm I tried replacing my widget content with some dummy text to confirm and am experiencing the same issue.
@jasongrout my ultimate goal is to automatically launch my extension on page startup/refresh. Could this also be achieved through the use of workspaces?
Referencing this page on jupyterlab urls: https://jupyterlab.readthedocs.io/en/stable/user/urls.html
-
I first opened my extension in my browser to create the layout I want on startup.
-
Next I created the workspace called testingworkspace from the current layout by following the url:
http://localhost:8888/lab/workspaces/testingworkspace?clone -
I then tried exporting the workspace into a json file to my cwd using:
jupyter lab workspaces export testingworkspace > testingworkspace.json -
The contents of my testingworkspace.json contained:
{“data”:{“layout-restorer:data”:{“main”:{“dock”:{“type”:“tab-area”,“currentIndex”:0,“widgets”:[]},“mode”:“multiple-document”},“left”:{“collapsed”:true,“widgets”:[“filebrowser”,“running-sessions”,“command-palette”,“jp-property-inspector”,“tab-manager”,“extensionmanager.main-view”]},“right”:{“collapsed”:true,“widgets”:[]}},“file-browser-filebrowser:cwd”:{“path”:""},"@jupyterlab/settingeditor-extension:plugin":{“sizes”:[0.25,0.75],“container”:{“plugin”:"@jupyterlab/shortcuts-extension:shortcuts",“sizes”:[0.4594017094017094,0.5405982905982906]}}},“metadata”:{“id”:"/lab/workspaces/testingworkspace"}} -
Then I imported the workspace from my cwd to my local store of workspaces at Users/user/.jupyter/lab/workspaces/ using:
jupyter lab workspaces import testingworkspace.json -
Finally, I tried opening the workspace by opening the following url in my browser:
http://localhost:8888/lab/workspaces/testingworkspace
Unfortunately, this url did not open the desired testingworkspace workspace but opened just a launcher (I assume it just opened a default workspace). Is this the correct workflow to save and open a custom workspace?
Not really, if I understand your goal correctly. To get your extension’s widget opened, creating it at activation is the way to go.
That is concerning. Can you make a very simple extension reproducing this, i.e., trying to open a widget at activation with just some plain text, and seeing it not consistently open?
Sorry @jasongrout for the very late reply Jason. Priorities changed and wasn’t able to revisit this issue until now.
Following your original recommendation
I was able to make my extension auto launch by simply replacing the launcher:create in the filebrowser-extension/lib/index.js with my command ignite-panel:create
Thanks for the help!
Peter