You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am not 100% sure that this functionality belongs in app-model, but I just wanted to get your thoughts @tlambert03
Negating a keybindings is a functionality in VScode and replicated in napari/napari#6204 . It is a way to make a specific keybinding inactivate, done so by adding a '-' to the start of a command ID string.
The reason is because we do not want to delete 'default' keybindings (i.e. app and plugin keybindings), thus we would like a way to make these inactive without removing them from the keybinding registry. This allows us to:
'restore default' keybindings
when a use 'overrides' a default keybinding with a new one (with a different key sequence) we need to ensure the over-ridden default keybinding is inactive (i.e., pressing the default keysequence does not do anything)
If we have functionality to store different sources of keybindings (#226), it seems reasonable (??) that this functionality (or something similar) would be useful. But I would understand if you think that this is too specific/up to individual users to implement and tailor for their own use.
Implementation:
We thought that it could be implemented in a method in keybinding registry or at dispatch. Implementing it as a registry method would allow it to be used for purposes outside of dispatch (maybe for e.g., command palette purposes?)
Description
I am not 100% sure that this functionality belongs in app-model, but I just wanted to get your thoughts @tlambert03
Negating a keybindings is a functionality in VScode and replicated in napari/napari#6204 . It is a way to make a specific keybinding inactivate, done so by adding a '-' to the start of a command ID string.
The reason is because we do not want to delete 'default' keybindings (i.e. app and plugin keybindings), thus we would like a way to make these inactive without removing them from the keybinding registry. This allows us to:
If we have functionality to store different sources of keybindings (#226), it seems reasonable (??) that this functionality (or something similar) would be useful. But I would understand if you think that this is too specific/up to individual users to implement and tailor for their own use.
Implementation:
We thought that it could be implemented in a method in keybinding registry or at dispatch. Implementing it as a registry method would allow it to be used for purposes outside of dispatch (maybe for e.g., command palette purposes?)
cc @DragaDoncila @dalthviz
The text was updated successfully, but these errors were encountered: