Adds quick settings button to the new launcher

[andrewfulton9]

Reference Issues or PRs

closes number #9

What does this implement/fix?

Adds a quick settings button to the new launcher

Put a x in the boxes that apply

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds a feature)
• Breaking change (fix or feature that would cause existing features not to work as expected)
• Documentation Update
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no API changes)
• Build related changes
• Other (please describe):

Testing

• Did you test the pull request locally?
• Did you add new tests?

Note that the query parameter for the command to open the settings editor only works if the default settings are in place

Documentation

Access-centered content checklist

Text styling

• The content is written with plain language (where relevant).
• If there are headers, they use the proper header tags (with only one level-one header: H1 or # in markdown).
• All links describe where they link to (for example, check the Nebari website).
• This content adheres to the Nebari style guides.

Non-text content

• All content is represented as text (for example, images need alt text, and videos need captions or descriptive transcripts).
• If there are emojis, there are not more than three in a row.
• Don't use flashing GIFs or videos.
• If the content were to be read as plain text, it still makes sense, and no information is missing.

Any other comments?

[github-actions]

👈 Launch a Binder on branch andrewfulton9/jupyterlab-new-launcher/quick_settings

[andrewfulton9]

@krassowski, I still need to add testing, but could you take a look when you get a chance. I think all the functionality is here for this one. There is one issue where the command for opening the settings editor for the new launcher only works if no default settings have been changed. Otherwise it opens the settings editor, but not to the New Launcher settings. Any idea what could be causing that?

[krassowski]

Thank you @andrewfulton9! I left a few suggestions.

I see what you mean about the query not having much of an effect if settings editor is already open. I would call this an upstream bug in JupyterLab, as it also affects jupyter-ai and other places where this command is used with query. I opened jupyterlab/jupyterlab#16479 to track it (we may want to address it or let it hang as a good first issue for a while, in any case it should not block this PR).

[krassowski]

Currently the menu is positioned within the browser window:

I wonder if it would be nicer if it was positioned relative to the launcher body or the button. You can pass a third argument to menu.open() with Menu.IOpenOptions object. Once jupyterlab/lumino#700 is released we will be able to pass a custom host but for now we could only try using forceX to improve the positioning.

[andrewfulton9]

It currently should be positioned to the button. It's just shifting the menu so it fits in the window. This is what it looks like when the panel isn't directly next the edge of the window:

If I use forceX the part of the menu isn't viewable which I think may be worse:

I wonder if there is a way to align it so the top-right corner of the menu aligns with the bottom right corner of the button. In my opinion that would look the cleanest.

[krassowski]

align it so the top-right corner of the menu aligns with the bottom right corner of the button. In my opinion that would look the cleanest.

💯 agree. There is no way as of today. Can you open a feature request on lumino, and another issue here to track it as a follow-up enhancement?

[andrewfulton9]

Sounds good. I opened Lumino#709 for this

[krassowski]

Currently it shows a generic "Settings Editor":

This is fine, though alternatively we could change it to "Open settings" by wrapping it in a custom command. Of note, it would be good to align the capitalization one way or another (I do not have a preference but I think other menus use Title Caps).

[andrewfulton9]

@krassowski, I added playwright tests and I think this is ready for another review when you get a chance

[krassowski]

I would suggest to drop this screenshot comparison and instead add something like:

const starredSection = page.locator('.jp-CollapsibleSection-Title:has-text("Starred")')
await expect(starredSection).toBeVisible();

(I have not tested these lines so they may need adjusting

[krassowski]

Let's remove this as flaky. We already have one snapshot for this state, testing by locator visibility should be sufficient and easier to maintain long term :)

[krassowski]

Thank you @andrewfulton9, looks great!