-
-
Notifications
You must be signed in to change notification settings - Fork 127
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
Pass _luminoEvent
argument when executing commands via keybinding
#644
Pass _luminoEvent
argument when executing commands via keybinding
#644
Conversation
Thanks for submitting your first pull request! You are awesome! 🤗 |
What would be a good place(s) to document this new argument? |
That's a good question. It looks like the Lumino docs aren't much more than the API reference, but the function that is directly changed here is private and isn't in the docs. I could add something to the docstring for |
packages/commands/src/index.ts
Outdated
@@ -613,15 +613,16 @@ export class CommandRegistry { | |||
*/ | |||
private _executeKeyBinding(binding: CommandRegistry.IKeyBinding): void { | |||
let { command, args } = binding; | |||
if (!this.hasCommand(command) || !this.isEnabled(command, args)) { | |||
let newArgs = { ...args, isKeybinding: true }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @andrewfulton9
To move further in the direction of passing the event information.
Should we set isKeybinding with the binding.keys
instead of a boolean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great question. For context we discussed exposing a subset of the event itself for menus, for an unrelated reason: jupyterlab/jupyterlab#14173 (comment)
I imagine we could go in the direction of having a ILuminoEvent
in which is (a) fully JSON-serializable, (b) includes context specific to Lumino applications (higher level concepts as type: "menu"
or type: "keybinding"
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@fcollonval, do you mean something like let newArgs = { ...args, isKeybinding: binding.keys };
? That would then allow for more customization in downstream actions. Am I understanding that correctly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was personally thinking:
newArgs = { ...args, event: { type: "keybinding", keys: binding.keys } }
or if we want to "hide" it:
newArgs = { ...args, _luminoEvent: { type: "keybinding", keys: binding.keys } }
or something in between. Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That seems reasonable to me. Would it always be type
and keys
for the _luminoEvent
? Would you just keep keys
blank if the event type was menu
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like ReadonlyPartialJSONObject
is readonly [key: string]
, so I don't think I can do that without changing ReadonlyPartialJsonObject
or updating CommandRegistry.execute
to include another args type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not see a problem here. Can you expand? In general the proposed event would be a union of types following a base interface for shared fields like "type". Such an interface/type w should indeed have read-only fields. It should conform to read-only JSON type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I may be misunderstanding an error. when I try to access newArgs._luminoEvent?.type
I am getting this error:
Property 'type' does not exist on type 'string | number | boolean | ReadonlyPartialJSONObject | ReadonlyPartialJSONArray'.
Property 'type' does not exist on type 'string'.ts(2339)
Any idea why it thinks _luminoEvent
is a string?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You will need to add a cast (with type guard). It should work since I've if the shower values is ReadonlyPartialJSONObject.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @andrewfulton9 it looks really nice. I like the idea of prefixing by _
added arguments.
Would you mind extending the following test to check it receives the new attribute with the correct value:
it('should add key bindings to the registry', () => { |
Thanks! I just added the test. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot @andrewfulton9
_luminoEvent
argument when executing commands via keybinding
Necessary for jupyterlab issue #15046 .
relevant discussion captured in #570.
Simply appends an
_luminoEvent
argument toargs
in_executeKeyBinding
.