Skip to content
This repository has been archived by the owner on Nov 6, 2019. It is now read-only.

Mac-only keyboard shortcut #438

Open
jasongrout opened this issue Oct 11, 2019 · 10 comments
Open

Mac-only keyboard shortcut #438

jasongrout opened this issue Oct 11, 2019 · 10 comments

Comments

@jasongrout
Copy link
Member

jasongrout commented Oct 11, 2019

I'd like to create a keybinding that only works on macs. Intuitively, I might imagine something like

           {
               "command": "notebook:create-console",
               "selector": ".jp-Notebook:focus",
               "macKeys": ["Cmd Shift ."]
           }

but I think that won't work in the current code (we assume keys is an array throughout the code, and this would make it undefined on non-Mac platforms). I could do this:

           {
               "command": "notebook:create-console",
               "selector": ".jp-Notebook:focus",
               "keys": [],
               "macKeys": ["Cmd Shift ."]
           }

but that assumes that the matching function at

function matchSequence(bindKeys: ReadonlyArray<string>, userKeys: ReadonlyArray<string>): SequenceMatch {
if (bindKeys.length < userKeys.length) {
return SequenceMatch.None;
}
for (let i = 0, n = userKeys.length; i < n; ++i) {
if (bindKeys[i] !== userKeys[i]) {
return SequenceMatch.None;
}
}
if (bindKeys.length > userKeys.length) {
return SequenceMatch.Partial;
}
return SequenceMatch.Exact;
}
is never called with userKeys being an empty list. I think that's valid - are we guaranteed that?

Note that I can't do

           {
               "command": "notebook:create-console",
               "selector": ".jp-Notebook:focus",
               "keys": ["Cmd Shift ."]
           }

because this would be translated to "Shift ." on non-mac platforms, which is not intuitive to me. I think the current behavior of ignoring Cmd on non-mac platforms should be changed to invalidating a keybinding if it contains Cmd on a non-mac platform.

@sccolbert
Copy link
Member

sccolbert commented Oct 12, 2019

The platform-specific keys are chosen during the normalization process:

keys = options.macKeys || options.keys;

So your second example should work. Note that the keybinding keys become the bindKeys argument in this function. The userKeys are the keys currently pressed by the user. So userKeys will always have .length >= 1 and bindKeys will have .length == 0 for non-Mac platforms:

if (bindKeys.length < userKeys.length) {

@sccolbert
Copy link
Member

(we assume keys is an array throughout the code, and this would make it undefined on non-Mac platforms)

No, it would make it a compile error if you have strictNullChecks turned on like you should ;-)

@jasongrout
Copy link
Member Author

No, it would make it a compile error if you have strictNullChecks turned on like you should ;-)

Touché

jasongrout added a commit to jasongrout/jupyterlab that referenced this issue Oct 12, 2019
Phosphor allows shortcuts to be empty, and it’s the only way to have platform-specific shortcuts (define keys to be [], and the platform keys to be something specific).

See phosphorjs/phosphor#438 for some discussion.
@jasongrout
Copy link
Member Author

So your second example should work.

I realized it's our fault in jlab that it won't work - we insist that keybindings have at least one item in them in our json schema. I've put in a PR fixing this: jupyterlab/jupyterlab#7335

@jasongrout
Copy link
Member Author

I think the current behavior of ignoring Cmd on non-mac platforms should be changed to invalidating a keybinding if it contains Cmd on a non-mac platform.

Chris, I think my questions are answered except the above one. What do you think about invalidating the entire keybinding if it contains Cmd on a non-mac platform. Otherwise you end up having bindings on non-mac platforms that you wouldn't didn't expect, or at least I wouldn't expect.

@vidartf
Copy link
Contributor

vidartf commented Oct 12, 2019

No, it would make it a compile error if you have strictNullChecks turned on like you should ;-)

@sccolbert That's a WIP for 2.0. Should we wait for #417, or go ahead with jupyterlab/jupyterlab#7002 ?

@sccolbert
Copy link
Member

@vidartf Wait for #417. I didn't realize you were blocked on me. I'll take care of it.

@sccolbert
Copy link
Member

@jasongrout By invalidate do you mean "ignore the entire keybinding" or "throw an exception"?

@jasongrout
Copy link
Member Author

@jasongrout By invalidate do you mean "ignore the entire keybinding" or "throw an exception"?

Ignore is probably most convenient to the end-user for me. Then the person registering the binding doesn't have to check to see if they are on a mac. I mean, clearly the keybinding won't be triggered on windows, so they won't even notice it's not there.

@sccolbert
Copy link
Member

Ignoring it sounds reasonable. Technically its a behavioral change, not an API change. Could probably be considered a bugfix.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants