The current Shortcuts module is limited in many ways. For example, the following scenario presents some problems:
Shortcuts are bound to the context menu and can only be invoked using shortcuts for menu actions when the menu is called up.
Problem: All menu operations should be able to be invoked with shortcuts when the context menu's target element is focused.
Differentiation of App Global Operations Web apps in Windows, macOS, Linux, and browsers have different shortcuts for global operations.
In an Electron App, there are some App-level shortcuts bound to the Main layer, which we call App Global Shortcuts. These do not exist in the Web App in the browser.
These shortcuts are listened to by the Electron Main process, which calls the corresponding action logic via a bridge.
Since global shortcuts are registered in Main, they are not perceived in the Renderer. Also, due to system variability, these shortcuts may behave differently on different systems. Also, in macOS, it is possible to recognize menu shortcuts by seeing the specific menu item through the system menu bar, but in other systems, it is not possible to see them in this way.
Shortcut Conflict Issues Between Multiple Scopes
At the moment, we only have Scopes for the following scenarios:
Home (App first screen dimension)
Modal (Modal is a separate dimension)
Menu (context menu)
When the shortcut key is switched to any Scope, the shortcut keys registered under other Scopes will be disabled.
For example, when Modal is on, all shortcuts in the App's first screen will be disabled by default. This makes sense to prevent conflict problems.
However, the current Scope distinction is still not granular enough.
For example, on the first screen of the App, there are 3 columns in the normal case. We call them FeedColumn, EntryColumn, EntryContent.
Under FeedColumn, there may be an audio player.
We set Space to toggle media pause/play, but in EntryContent we set Space to scroll down the content. Since we are in the same Scope, this will cause a conflict.
For example, we have bound the up and down arrow keys to toggle the up and down Entry, but we can't bind the arrow keys to toggle the up and down feeds.
Proposal
For this improvement, I propose an ideal Scope division and shortcut registration model.
Looking at the whole App, it is divided into the following layers from top to bottom, with the lower the layer, the higher the priority.
App Global Layer
Layout Layer
Focusable Layer
Float Layer
App Global Layer
In Electron App, the global shortcuts are registered by Main, and the related operations are invoked through the bridge.
In a Web App, a separate hook is used to register the action in response.
These operations should be available to the entire App.
Example operations: basic operations such as copy/paste. Quickly adding subscriptions (CMD+N) etc.
Layout Layer
Differential partitioning of shortcuts according to page.
These shortcuts are globally available for this Layout.
The Layout should be strongly related to the Router.
Examples of global actions available in a 3-column layout are: jump to Discover page (CMD+T), etc.
Focusable Layer
Shortcuts are available when an element is focused.
For a three-column layout, we can refine each column to a Scope, so that when the focus switches to any column, the Scope switches at the same time.
Then we can use the up and down arrow keys for different purposes in different columns.
Focus can be refined to each list item, when Focus is on a list element, it should make every option in the context menu of that list item available for shortcuts, even if the context menu is not called up.
Note that. Focus elements in a Focusable Layer should be bubbled. For example, a list element is focused, and the element is in a FeedColumn. Its shortcut priority should be, the context menu shortcut for that item - the FeedColumn shortcut.
Float Layer
This layer distinguishes between the original Menu and Modal Scope, the Float Layer is a special layer that is accessed when the Modal and ContextMenu are opened, and should be blocked from other layers to ensure that shortcut triggering is limited to the current layer.
linear[bot]
commented
3 hours ago
Motivation
The current Shortcuts module is limited in many ways. For example, the following scenario presents some problems:
Problem: All menu operations should be able to be invoked with shortcuts when the context menu's target element is focused.
In an Electron App, there are some App-level shortcuts bound to the Main layer, which we call App Global Shortcuts. These do not exist in the Web App in the browser.
These shortcuts are listened to by the Electron Main process, which calls the corresponding action logic via a bridge.
Since global shortcuts are registered in Main, they are not perceived in the Renderer. Also, due to system variability, these shortcuts may behave differently on different systems. Also, in macOS, it is possible to recognize menu shortcuts by seeing the specific menu item through the system menu bar, but in other systems, it is not possible to see them in this way.
At the moment, we only have Scopes for the following scenarios:
When the shortcut key is switched to any Scope, the shortcut keys registered under other Scopes will be disabled.
For example, when Modal is on, all shortcuts in the App's first screen will be disabled by default. This makes sense to prevent conflict problems.
However, the current Scope distinction is still not granular enough.
For example, on the first screen of the App, there are 3 columns in the normal case. We call them FeedColumn, EntryColumn, EntryContent.
Under FeedColumn, there may be an audio player.
We set Space to toggle media pause/play, but in EntryContent we set Space to scroll down the content. Since we are in the same Scope, this will cause a conflict.
For example, we have bound the up and down arrow keys to toggle the up and down Entry, but we can't bind the arrow keys to toggle the up and down feeds.
Proposal
For this improvement, I propose an ideal Scope division and shortcut registration model.
Looking at the whole App, it is divided into the following layers from top to bottom, with the lower the layer, the higher the priority.
App Global Layer
In Electron App, the global shortcuts are registered by Main, and the related operations are invoked through the bridge.
In a Web App, a separate hook is used to register the action in response.
These operations should be available to the entire App.
Example operations: basic operations such as copy/paste. Quickly adding subscriptions (CMD+N) etc.
Layout Layer
Differential partitioning of shortcuts according to page.
These shortcuts are globally available for this Layout.
The Layout should be strongly related to the Router.
Examples of global actions available in a 3-column layout are: jump to Discover page (CMD+T), etc.
Focusable Layer
Shortcuts are available when an element is focused.
For a three-column layout, we can refine each column to a Scope, so that when the focus switches to any column, the Scope switches at the same time.
Then we can use the up and down arrow keys for different purposes in different columns.
Focus can be refined to each list item, when Focus is on a list element, it should make every option in the context menu of that list item available for shortcuts, even if the context menu is not called up.
Note that. Focus elements in a Focusable Layer should be bubbled. For example, a list element is focused, and the element is in a FeedColumn. Its shortcut priority should be, the context menu shortcut for that item - the FeedColumn shortcut.
Float Layer
This layer distinguishes between the original Menu and Modal Scope, the Float Layer is a special layer that is accessed when the Modal and ContextMenu are opened, and should be blocked from other layers to ensure that shortcut triggering is limited to the current layer.