Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Command palette interaction #447

Closed
ellisonbg opened this issue Jul 18, 2016 · 6 comments
Closed

Command palette interaction #447

ellisonbg opened this issue Jul 18, 2016 · 6 comments
Assignees
Labels
enhancement status:Needs Discussion status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion. tag:Design and UX
Milestone

Comments

@ellisonbg
Copy link
Contributor

Right now the command palette has some awkward interactions:

  • When you open the CP with Command+Shift+P, it focuses the search field and you can type and press enter to run the command. But there is no visual indication the command was run. The search field is still populated/filtered and the original selected item is still selected. Running a command should completely reset the search field and selection.
  • After you run a command, you can't keep working on your previous activity as the CP is still focused. We should focus the previous activity.
  • If you ran a command, go back to your activity and they try to run another command, the CP collapses. This makes it impossible to run multiple commands in a row. Command+Shift+P should always open (not toggle) the CP.

We might eventually want to move the CP away from the L side panel, but let's first get the interactions right and see how it feels.

@ellisonbg ellisonbg added this to the 0.90 milestone Jul 18, 2016
@sccolbert
Copy link
Contributor

A couple points to this:

(1) What you describe used to be the behavior. We opted with the current behavior as this is what sublime does (except that sublime closes the palette on each command execution). I have no strong opinion on this either way.

(2) The input field is focused and selected before the command is run. So if the command execution sets focus to something, that thing will remain focused. In general, the command palette has no way of knowing what was previously focused. I think the best course of action is to allow the command to decide what should get focus.

(3) Yep. Some of us talked about this briefly as Scipy and seemd to agree Cmd+Shift+P should always open the command palette instead of toggle it. And Esc should probably close it. However to be clear, this is only adjust the default key bindings, and will be completely user-specifiable in the future.

@jasongrout
Copy link
Contributor

(1) Some ideas: perhaps even a temporary indication, such as the command entry in the command palette blinking once or twice when executed, would help provide visual feedback that a command was executed. And then once the command is executed, deselect the command, but leave the filter left in place and selected, as is currently done.

@jasongrout
Copy link
Contributor

+1 to Cmd+Shift+P always opening, and Esc closing when the palette is focused.

@jasongrout
Copy link
Contributor

After you run a command, you can't keep working on your previous activity as the CP is still focused. We should focus the previous activity.

We decided in the JLab meeting that this was a bad idea. The command itself should focus if desired, but the command palette wouldn't know where to focus.

@ellisonbg
Copy link
Contributor Author

I think this can be closed.

@jasongrout
Copy link
Contributor

But there is no visual indication the command was run.

(1) Some ideas: perhaps even a temporary indication, such as the command entry in the command palette blinking once or twice when executed, would help provide visual feedback that a command was executed.

This was not addressed, but I'll open another issue for it.

@lock lock bot added the status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion. label Aug 10, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Aug 10, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement status:Needs Discussion status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion. tag:Design and UX
Projects
None yet
Development

No branches or pull requests

4 participants