Tenets higher in the list have precedence over tenets lower in the list.
Users Have Control - Terminal.Gui provides default key bindings consistent with these tenets, but those defaults are configurable by the user. For example, ConfigurationManager
allows users to redefine key bindings for the system, a user, or an application.
More Editor than Command Line - Once a Terminal.Gui app starts, the user is no longer using the command line. Users expect keyboard idioms in TUI apps to be consistent with GUI apps (such as VS Code, Vim, and Emacs). For example, in almost all GUI apps, Ctrl-V
is Paste
. But the Linux shells often use Shift-Insert
. Terminal.Gui binds Ctrl-V
by default.
Be Consistent With the User's Platform - Users get to choose the platform they run Terminal.Gui apps on and those apps should respond to keyboard input in a way that is consistent with the platform. For example, on Windows to erase a word to the left, users press Ctrl-Backspace
. But on Linux, Ctrl-W
is used.
The Source of Truth is Wikipedia - We use this Wikipedia article as our guide for default key bindings.
Terminal.Gui provides the following APIs for handling keyboard input:
The Key
class provides a platform-independent abstraction for common keyboard operations. It is used for processing keyboard input and raising keyboard events. This class provides a high-level abstraction with helper methods and properties for common keyboard operations. Use this class instead of the low-level KeyCode
enum when possible.
See Key for more details.
The default key for activating a button is Space
. You can change this using
Keybindings.Clear
and Keybinding.Add
methods:
var btn = new Button ("Press Me");
btn.Keybinding.Remove (Command.Accept);
btn.KeyBinding.Add (Key.B, Command.Accept);
The Command enum lists generic operations that are implemented by views. For example Command.Accept
in a Button
results in the Clicked
event
firing while in TableView
it is bound to CellActivated
. Not all commands
are implemented by all views (e.g. you cannot scroll in a Button
). Use the GetSupportedCommands()
method to determine which commands are implemented by a View
.
A HotKey is a keypress that selects a visible UI item. For selecting items across View
s (e.g. a Button
in a Dialog
) the keypress must have the Alt
modifier. For selecting items within a View
that are not View
s themselves, the keypress can be key without the Alt
modifier. For example, in a Dialog
, a Button
with the text of "_Text" can be selected with Alt-T
. Or, in a Menu
with "_File _Edit", Alt-F
will select (show) the "_File" menu. If the "_File" menu has a sub-menu of "_New" Alt-N
or N
will ONLY select the "_New" sub-menu if the "_File" menu is already opened.
By default, the Text
of a View
is used to determine the HotKey
by looking for the first occurrence of the HotKeySpecifier (which is underscore (_
) by default). The character following the underscore is the HotKey
. If the HotKeySpecifier
is not found in Text
, the first character of Text
is used as the HotKey
. The Text
of a View
can be changed at runtime, and the HotKey
will be updated accordingly. HotKey is virtual
enabling this behavior to be customized.
**
A Shortcut is a keypress that invokes a Command or View
-defined action even if the View
that defines them is not focused or visible (but the View
must be enabled). Shortcuts can be any keypress; Key.A
, Key.A | Key.Ctrl
, Key.A | Key.Ctrl | Key.Alt
, Key.Del
, and Key.F1
, are all valid.
Shortcuts
are used to define application-wide actions (e.g. Quit
), or actions that are not visible (e.g. Copy
).
MenuBar, ContextMenu, and StatusBar support Shortcut
s.
Keyboard events are retrieved from Console Drivers and passed on to the Application class by the Main Loop.
Application then determines the current Toplevel view
(either the default created by calling Application.Init
, or the one set by calling Application.Run
). The mouse event, using Bounds-relative coordinates is then passed to the NewKeyDownEvent method of the current Toplevel view.
If the view is enabled, the NewKeyDownEvent method will do the following:
1) If the view has a subview that has focus, 'ProcessKeyDown' on the focused view will be called. If the focused view handles the keypress, processing stops. 2) If there is no focused sub-view, or the focused sub-view does not handle the keypress, OnKeyDown will be called. If the view handles the keypress, processing stops. 3) If the view does not handle the keypress, OnInvokingKeyBindings will be called. This method callsInvokeKeyBindings to invoke any keys bound to commands. If the key is bound and any of it's command handlers return true, processing stops. 4) If the key is not bound, or the bound command handlers do not return true, OnProcessKeyDow is called. If the view handles the keypress, processing stops.
To define global key handling logic for an entire application in cases where the methods listed above are not suitable, use the Application.OnKeyDown
event.
Terminal.Gui supports key up/down events with OnKeyDown and OnKeyUp, but not all Console Drivers do. To receive these key down and key up events, you must use a driver that supports them (e.g. WindowsDriver
).
ConsoleDriver
.Application
subscribes to ConsoleDriver.Down/Up
events and forwards them to the most-focused TopLevel
view using View.NewKeyDownEvent
and View.NewKeyUpEvent
.The base (View
) implementation of NewKeyDownEvent
follows a pattern of "Before", "During", and "After" processing:
Enabled == false
that view should never see keyboard (or mouse input).NewKeyDownEvent
is called on the most-focused SubView (if any) that has focus. If that call returns true, the method returns.OnKeyDown
.OnKeyDown
call returns false (indicating the key wasn't handled)
OnInvokingKeyBindings
is called to invoke any bound commands.OnInvokingKeyBindings
fires the InvokingKeyBindings
eventOnInvokingKeyBindings
returns false (indicating the key wasn't handled)
OnProcessKeyDown
is called to process the key.OnProcessKeyDown
fires the ProcessKeyDown
eventSubclasses of View
can (rarely) override OnKeyDown
to see keys before they are processed by OnInvokingKeyBindings
and `OnProcessKeyDown
Subclasses of View
can (rarely) override OnInvokingKeyBindings
to see keys before they are processed by OnProcessKeyDown
Subclasses of View
can (often) override OnProcessKeyDown
to do normal key processing.
Command
or KeyBindings
KeyCode
enum.KeyDown/Up
events. The OnKey/Down/Up
methods are public and can be used to simulate keyboard input (in addition to SendKeys).KeyBindingScope.Application
.KeyDown/Up
events (via Handled = true
). The OnKey/Down/Up/
methods are public and can be used to simulate keyboard input.KeyBindingScope.View
and KeyBindingScope.HotKey
.NewKeyDownEvent
and NewKeyUpEvent
. These methods are called by Application
can be called to simulate keyboard input.OnKeyDown
and OnKeyUp
. These methods are called by NewKeyDownEvent
and NewKeyUpEvent
and can be overridden to handle keyboard input.