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

keybindings: add context menu to keyboard shortcuts #12791

Merged
merged 7 commits into from
Oct 21, 2023

Conversation

pisv
Copy link
Contributor

@pisv pisv commented Aug 1, 2023

What it does

Fixes the bulk of #7582.

Adds a context menu to the Keyboard Shorcuts editor with the following menu items:

  • Copy
  • Copy Command ID
  • Copy Command Title
  • Edit Keybinding...
  • Edit When Expression...
  • Add Keybinding...
  • Remove Keybinding
  • Reset Keybinding
  • Show Same Keybindings

This PR does not address the bonus part of #7582, i.e. no keybindings are provided for the menu items.

How to test

Verify that each of the new context menu items works as expected, i.e. similar to how it works in VS Code.

Review checklist

Reminder for reviewers

Fixes the bulk of eclipse-theia#7582.

Adds a context menu to the Keyboard Shorcuts editor
with the following menu items:

- Copy
- Copy Command ID
- Copy Command Title
- Edit Keybinding...
- Edit When Expression...
- Add Keybinding...
- Remove Keybinding
- Reset Keybinding
- Show Same Keybindings

This commit does not address the bonus part of eclipse-theia#7582,
i.e. no keybindings are provided for the menu items.
@vince-fugnitto vince-fugnitto added the keybindings issues related to keybindings label Aug 1, 2023
* Show keybinding items with the same key sequence as the given item.
* @param item the keybinding item
*/
public showSameKeybindings(item: KeybindingItem): void {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

public is not necessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your review and comments, Thomas. Let me try to address your concerns.

The public modifiers can be omitted in TypeScript, of course.

However, I aimed at stylistic consistency with the surrounding code here, where both of the directly preceding methods hasSearch() and clearSearch() have already had the public modifier. Also, I didn't find it mentioned in the style guide at all.

However, if you do dislike them, I can remove all the public modifiers in my code, no problem. In that case, may I humbly suggest the style guide probably needs to be updated accordingly?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, of course, that there is no guidance in the style guide. However, most code in Theia does not use public. I usually remove it when I touch a piece of code. But it's not a reason to reject the PR, of course.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. I'll remove all the public modifiers in the KeybindingWidget then, including the old code, for the sake of stylistic consistency, if you don't mind. It seems that I haven't introduced any public modifiers elsewhere.

protected handleItemContextMenu(item: KeybindingItem, index: number, event: React.MouseEvent<HTMLElement>): void {
event.preventDefault();
this.selectItem(item, index, event.currentTarget);
setTimeout(() => this.contextMenuRenderer.render({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the setTimout()?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it should be necessary, the context menu renderer is used in other places without it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. I'll remove it then.

packages/keymaps/src/browser/keybindings-widget.tsx Outdated Show resolved Hide resolved
@@ -49,6 +51,33 @@ export namespace KeymapsCommands {
id: 'keymaps.clearSearch',
iconClass: codicon('clear-all')
};
export const COPY_KEYBINDING: Command = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe these should be i18n-ed

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure that I understood it correctly. These commands are not intended to be shown in the command palette and, therefore, don't have a label that could be localized. They are meant to be used only in the context menu of the keyboard shortcuts editor, where each menu item does have a localized label.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can set a keybinding for those commands, so they are visible in the keybindings widget 🤷

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sorry if I'm again missing something, but I still don't think these commands should have a label, as this would have made them accessible to the user from the command palette. These commands would not work correctly if invoked from the command palette, as they require specific arguments, which would not have been provided in this case.

There are similar places in the existing code where such commands don't have a label like

export namespace ConsoleCommands {
export const SELECT_ALL: Command = {
id: 'console.selectAll'
};
export const COLLAPSE_ALL: Command = {
id: 'console.collapseAll'
};
export const CLEAR: Command = {
id: 'console.clear'
};
export const EXECUTE: Command = {
id: 'console.execute'
};
export const NAVIGATE_BACK: Command = {
id: 'console.navigatePrevious'
};
export const NAVIGATE_FORWARD: Command = {
id: 'console.navigateNext'
};
}
or
export const APPEND: Command = {
id: 'output:append'
};
export const APPEND_LINE: Command = {
id: 'output:appendLine'
};
export const CLEAR: Command = {
id: 'output:clear'
};
export const SHOW: Command = {
id: 'output:show'
};
export const HIDE: Command = {
id: 'output:hide'
};
export const DISPOSE: Command = {
id: 'output:dispose'
};

It looks like a pattern to me, or am I missing something?

Copy link
Contributor

@tsmaeder tsmaeder Oct 19, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even if everyone else is doing it this way, it might still be wrong ;-). What I'm saying is this: if we're using a command, you can assign a keybinding to it, so the command will show up in the keybinding widget, but it won't show up with the proper title.
Whether we show the command in the command quick-pick should be a separate concern. Does the command show up if you properly enable/disable the handler depending on the context (like having the keybinding editor active)?

Copy link
Contributor Author

@pisv pisv Oct 19, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your are right. Looks like I was misguided by existing code then.

I have just checked that the new commands, even when they do have a label, don't actually show up in the command quick-pick.

Do you think that a separate category should also be used for the new commands (e.g. 'Keybindings')?

Thank you for your guidance, I really appreciate it!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just for the record, it looks like the corresponding commands in VS Code don't have a label. To see it, just search for keybindings. in the Keyboard Shortcuts editor in VS Code. I have suddenly discovered it when trying to find out what category (if any) those commands are in VS Code.

Having said that, I agree with your point in general, and just wanted to be sure we were still on the same page in this specific case.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think that a separate category should also be used for the new commands (e.g. 'Keybindings')?

I think VS Code uses "Preferences" as the category for keybindings-related commands. I don't see any value in behaving differently.

it looks like the corresponding commands in VS Code don't have a label

Having a proper label for commands is the right thing to do, IMO.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. I have submitted the requested changes for your consideration.

@tsmaeder tsmaeder self-requested a review October 20, 2023 14:23
Copy link
Contributor

@tsmaeder tsmaeder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm now.

@tsmaeder tsmaeder merged commit 825c092 into eclipse-theia:master Oct 21, 2023
13 checks passed
@pisv pisv deleted the GH-7582 branch October 21, 2023 10:31
@vince-fugnitto vince-fugnitto added this to the 1.43.0 milestone Oct 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
keybindings issues related to keybindings
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

None yet

3 participants