Bigger or multi-column menu? about vscode-which-key HOT 11 CLOSED

That's awesome!! Multi-column might possible with some more css magic, but I assume arrow keys are going to be weird with multi-column.

Anyway, I think this workaround is worth documenting especially I don't think vscode will get to that issue any time soon.

@The-Compiler Wondering would you mind documenting your workaround to https://github.com/VSpaceCode/vspacecode.github.io/blob/master/docs/bonus.md? And we can close out this issue.

from vscode-which-key.

For reference, here's the setting for the (rather buggy) three-column menu:

        ".quick-input-widget > .quick-input-list .monaco-list-rows":
          "display: grid !important; grid-template-columns: repeat(3, 1fr); grid-auto-rows: 1.5em;",
        ".quick-input-widget > .quick-input-list .monaco-list-row":
          "position: unset !important;",

As for the text colors, that's yet another hack just matching text starting with a +:

        ".quick-input-widget > .quick-input-list .monaco-list-row[aria-label*=\"  +\"] .label-description":
          "color: #8ec07c !important;",

and the icon styling:

        ".quick-input-widget > .quick-input-list .codicon":
          "color: #83a598 !important; padding-right: 8px;",

from vscode-which-key.

Thank you for liking the extension. You are right that we certainly limited by what we can do with the vscode API. The QuickMenu is what we use to render to list; we don't have many options to customize it. Multiple column, and location of the location of the QuickPick are not customizable.

However, a long shot is to experiment with something like a (custom web view)[https://code.visualstudio.com/api/extension-guides/webview] in the bottom pane. However, my gut sense is that the challenge would be shifting the focus back to where it was.

An other alternative could be trying out the sort option in which-key config that might help discoverability. We can also implement a custom sort option that shows command binding first.

from vscode-which-key.

I closed this by accident.

from vscode-which-key.

Thanks for the quick reply! FWIW I managed to find a workaround for this, based on microsoft/vscode#85374.

It's an ugly workaround using Customize UI, which then uses Monkey Patch which patches VS Code's code when it's launched... Not saying I'm happy about it, but now I can do:

    "customizeUI.stylesheet": {
        ".quick-input-widget > .quick-input-list > .monaco-list": "max-height: none !important;"
    },

and get:

so I guess if it's stupid and it works, it ain't stupid 😉

from vscode-which-key.

@The-Compiler Wondering would you mind documenting your workaround to https://github.com/VSpaceCode/vspacecode.github.io/blob/master/docs/bonus.md? And we can close out this issue.

I can do that! (Though I might be away for a couple of days first.)

Should that really be in bonus.md, or perhaps rather whichkey/extra.md (with a link in bonus.md like the others), given that it's not VSpaceCode-specific?

from vscode-which-key.

Should that really be in bonus.md, or perhaps rather whichkey/extra.md (with a link in bonus.md like the others), given that it's not VSpaceCode-specific?

That makes perfect sense :)

from vscode-which-key.

I'm still tinkering with this some more before adjusting docs. Multi-column is definitely possible with some more CSS injection:

but it pretty much breaks other quick inputs:

would be great to only apply it to quick inputs coming from vscode-which-key, but I don't see a way to tell them apart. The best thing I can think of is matching whether the title is VSpaceCode or starting with a +... (doesn't seem possible as it's in the text and not in an aria-label)

from vscode-which-key.

That very impressive. Yeah, I am not sure what we can do since we don't control the rendering and I also assume the quickpick menu css is shared across different menu.

Btw, how did you get different colors text?

from vscode-which-key.

Okay, I'm giving up on the multi-column thing, I don't see a way to do this without breaking all other quick inputs unfortunately.

Time to add the height workaround to the docs then! What branch should I open a PR for, though? Should I use the refactor branch for the vspacecode.github.io repo as well?

from vscode-which-key.

That's a bummer, but it looks really cool tho.

Since this is not tied to any version, I don't think it needs to be on the refactor branch. We have -next for the unreleased documentation. I think you can even just have a PR to master.

from vscode-which-key.