Command Tool [AARD-2079]

[AlexD717]

Task

Create a command tool, that allows synthesis users to type in "/" followed by a command that then executes a specific action.

AARD-2079

Symptom

It can get annoying for developers and users to have to go through multiple panels to achive what they want. For advanced users of Synthesis a command tool would let them quickly type commands to implement a specific action. For example, instead of having to go to debug tools, then clicking toggle drag mode, then clicking hide debug tools panel, you could just type "/drag mode" and it will toggle the drag mode.

Solution

Implement a simple Command palette that appears when pressing "/" and lists options of different commands. It uses an algorithm to determine what you are most likely typing and then suggesting that as an option. This means that both "/drag" or "/drqg" (typo example) will triggle the toggle drag mode command.

Verification

• Pressing "/" opens up a command pallet
  • Doesn't open in the welcome screen (singleplayer/multiplayer selection screen)
  • Doesn't open if a modal is open
• Pressing "esc" closes the command palette
• Starting to type in a command has different options appear, with options that you most likely want appearing at the bottom
• pressing enter runs the command you have selected (or clicking on the command with the mouse)
• Can use arrow keys to navigate between selected commands (or mouse)
• Clicking outside of the command palette closes it

---

Before merging, ensure the following criteria are met:

• All acceptance criteria outlined in the ticket are met.
• Necessary test cases have been added and updated.
• A feature toggle or safe disable path has been added (if applicable).
• User-facing polish:
  • Ask: "Is this ready-looking?"
• Cross-linking between Jira and GitHub:
  • PR links to the relevant Jira issue.
  • Jira ticket has a comment referencing this PR.

[azaleacolburn]

Doesn't open in menu selection

1. I'm not sure what you mean by this, but it does still open when you have panels open (including the main menu panel which is what I assume you mean). If you mean within the command palette, then yes indeed typing / doesn't open another one.
2. I like how the drag mode command works, I think the commands that open panels should toggle them instead.
3. I think that trying to navigate past the first or last option should wrap around to the other end of the list.

[AlexD717]

Doesn't open in menu selection

1. I'm not sure what you mean by this, but it does still open when you have panels open (including the main menu panel which is what I assume you mean). If you mean within the command palette, then yes indeed typing / doesn't open another one.

I meant the welcome screen. Will clarify that

I agree with your other suggestions and will implement them

[AlexD717]

2. I like how the drag mode command works, I think the commands that open panels should toggle them in

Waiting on pr #1268 to be merged in first, as that implements support for detecting if panels/modals are already opened

[rutmanz]

1. Looks like typing in the search bar also drives robots around (WASD and arrow keys)
2. I think whenever you reference a robot name, you should also reference the control scheme name (currently two dozers can't be distinguished)

[rutmanz]

The Luna scheme conflicts with this binding. I would either make the triggering key rebindable or prevent inputs from using it

[itspvty]

I really like this concept overall and the use of fuse.js is very cool.

[ryanzhangofficial]

love it!

[PepperLola]

Could you get rid of this highlight ring?

Also, I think it would be worth adding options for the different tabs of the configure panel just like there are for spawning.

[AlexD717]

Could you get rid of this highlight ring?

In my opinion, the command pallet without any border looks weird, when you have something other than the bottom part selected.

If I make the boarder 1px dark grey, it adds a slight line, which separates the text box, making it more clear.

Are you fine with the second option or do you still think the first is better? (@PepperLola)

[azaleacolburn]

I like the last option best personally

[PepperLola]

I like the separator but I think it would make sense either to have the border around the whole thing or just have a separator between the input and the options (only the top of the input), and maybe then get rid of the border radius on the top left and right.

[PepperLola]

When I added a bunch of new commands, they weren't all accessible since it was only including enough to fit. I think the list should have a max height but should be scrollable and include all the registered commands

[AlexD717]

I like the separator but I think it would make sense either to have the border around the whole thing

The border is around the whole thing right now

When I added a bunch of new commands, they weren't all accessible since it was only including enough to fit. I think the list should have a max height but should be scrollable and include all the registered commands

If you start typing it very quickly filters them out

[PepperLola]

If you start typing it very quickly filters them out

That's true, but I think you should be able to scroll through all of them to see what options are available. It's true that you can filter some out so I guess it's not super important to include in this PR but I definitely think it would be worthwhile to add.

EDIT: on second thought, I think it should be included in this PR as it's pretty core functionality and I think necessary for a good user experience

[PepperLola]

I think it looks good. It would be nice if the scrolling were smooth, and there were a couple bugs I couldn't figure out how to consistently reproduce (sometimes it would always scroll the selected option to the second slot from the top, regardless of whether I was scrolling up or down). I think it's in a good state to be merged, keeping these fixes in mind for the future.