mirror of
https://github.com/gui-cs/Terminal.Gui.git
synced 2025-12-28 16:58:01 +01:00
* Refactor selectors and improve UI components Refactored `MarginEditor` and `UICatalogTop` to use new `OptionSelector` and `FlagSelector` classes, introducing type-safe generic versions for better flexibility and maintainability. Added `SelectorBase` as a shared foundation for these components, along with the `SelectorStyles` enum for customizable styles. Enhanced unit tests to cover new implementations and edge cases. Enabled nullable reference types for improved null safety. Improved code readability, reduced redundancy, and enhanced user experience with better hotkey management, focus handling, and layout adjustments. * Refactor UI components and remove unused classes Significant refactoring and simplification of the codebase: - Updated `CharacterMap` to use `OptionSelector<UnicodeCategory>`. - Removed `FlagSelector`, `FlagSelector<TEnum>`, and `FlagSelectorStyles`. - Replaced `OptionSelector.Options` with `Labels` in `MenuBarv2`. - Removed `OptionSelector` and its associated properties/methods. - Updated terminology from "Activate" to "Select" across components. - Refactored `SelectorBase` to align with new "Select" behavior. - Removed redundant methods, properties, and event handlers. These changes streamline the codebase, reduce complexity, and align with updated design principles. * Fixes #4374 - 'Application.Screen' is empty when 'Init' returns Refactor and enhance testability of ApplicationImpl Refactored `ApplicationImpl` and related classes to improve modularity and testability. Replaced `FakeConsoleOutput` with `FakeOutput` and introduced `FakeInput` for better test isolation. Added platform-specific factories (`FakeNetComponentFactory`, `FakeWindowsComponentFactory`) to simplify fake component creation. Refactored `GuiTestContext` into partial classes, adding methods for simulating user interactions and improving initialization logic. Enhanced error handling and logging during test setup. Updated tests to use the new `FakeOutput` and `FakeInput` implementations. Standardized driver initialization with `Application.Init(null, "fake")`. Skipped tests relying on the fake driver due to known issues. Performed general cleanup, modernized syntax, and removed redundant code to improve readability and maintainability. * Disable "windows" test case in SynchronizationContextTests The `InlineData("windows")` attribute in the `SynchronizationContext_Post` test method has been commented out. This change temporarily excludes the `"windows"` driverName from the test suite while retaining other test cases (`"fake"`, `"dotnet"`, and `"unix"`). The exclusion may be for debugging, deprecation, or other maintenance purposes. * Disable "windows" test case in SynchronizationContextTests The `[InlineData("windows")]` attribute in the `SynchronizationContextTests` class has been commented out, disabling the test case for the `"windows"` driver name. This change may have been made for debugging, deprecation, or because the test is no longer relevant. Other test cases (`"fake"`, `"dotnet"`, and `"unix"`) remain active. * Update Terminal.Gui/Drivers/FakeDriver/FakeConsole.cs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * Update Terminal.Gui/Views/Selectors/SelectorStyles.cs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * Update Terminal.Gui/Views/Selectors/SelectorBase.cs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * Update Terminal.Gui/Views/Selectors/OptionSelector.cs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * Update Terminal.Gui/Views/Selectors/OptionSelector.cs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * Update Terminal.Gui/Views/Selectors/OptionSelector.cs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * Update Terminal.Gui/Views/Selectors/SelectorBase.cs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * Backported Checkbox from Activate PR * Backported Checkbox from Activate PR 2 * Backported Checkbox from Activate PR 3 * Backported Selctors Scenario * Backported Bars Scenario * Backported AllViewsTester Scenario * Backported Dialogs Scenario * Backported MessageBoxes Scenario * Backported ArrangementEditor * Backported mouse binding fix * Update Terminal.Gui/Views/Selectors/OptionSelector.cs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * Update Terminal.Gui/Drivers/WindowsDriver/WindowsOutput.cs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * Update Terminal.Gui/Views/CheckBox.cs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * Fixed typo * Refactor ArrangementEditor event handling Removed the `ArrangementFlagsOnValueChanged` method, which previously handled updates to `ViewToEdit` properties based on arrangement flags. Updated `ArrangementEditor_Initialized` to attach the event handler to `_arrangementSelector.ValueChanged`. The logic for handling arrangement changes has been refactored or relocated. * Refactor AlignKeys for type safety and readability Updated the `AlignKeys` method in the `Shortcuts` class to replace generic `View` references with the more specific `Shortcut` type. Improved type safety by using `IEnumerable<Shortcut>` and `.Cast<Shortcut>()`. Simplified the `max` calculation logic with a single LINQ query and removed redundant casting in the `foreach` loop. These changes enhance code readability, maintainability, and ensure better type safety. * Refactor ArrangementEditor for clarity and consistency Refactored `ArrangementEditor` to improve code readability and maintainability: - Enabled nullable reference types with `#nullable enable`. - Removed unused `using` directives. - Adjusted namespace declaration for formatting consistency. - Reformatted `_arrangementSelector` initialization and property assignment. - Simplified `OnViewToEditChanged` logic with a ternary expression. - Refactored `ArrangementEditor_Initialized` into a single-line block. * Update Examples/UICatalog/Scenarios/Shortcuts.cs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * Update Terminal.Gui/Views/Selectors/OptionSelector.cs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * Refactor and enhance OptionSelector and SelectorBase Refactored `OptionSelector` and `SelectorBase` to simplify logic, improve hotkey assignment, and ensure robust behavior. Updated `Shortcuts.cs` and `DialogTests.cs` to address nullability issues. Added comprehensive unit tests for `OptionSelector` and `SelectorBase`, covering properties, methods, edge cases, and layout behaviors. These changes improve code readability, maintainability, and functionality while adhering to modern C# practices. * add FlagSelector comprehensive tests Refactored `UncheckNone` and `UncheckAll` methods in `FlagSelector` to improve clarity and prevent concurrent modifications using a new `_updatingChecked` flag. Removed the old `UncheckNone` implementation and reorganized logic for maintainability. Added extensive unit tests in `FlagSelectorTests` to validate functionality, including edge cases and generic implementations. Tests cover flag combination, toggling, "None" flag behavior, and enum-based generic handling. Improved overall maintainability and test coverage for the `FlagSelector` class. * Fixes #4375. UnixDriver fails Toplevel_TabGroup_Forward_Backward Fluent Tests * Refactor RadioGroup to use OptionSelector The `RadioGroup` class has been refactored to inherit from the `OptionSelector` class instead of `View`, marking it as `[Obsolete]` and recommending the use of `OptionSelector`. The previous implementation of `RadioGroup` has been entirely removed, including its properties, methods, events, and internal logic. This includes initialization logic, key bindings, layout management, and event handling. The new `RadioGroup` is now a thin wrapper around `OptionSelector` and implements the `IDesignable` interface. The `EnableForDesign` method has been simplified to set default options for design purposes. This change simplifies the codebase and encourages the use of `OptionSelector` for managing mutually exclusive options. * Backported focus tests and add bug-exposing test case Refactored `AdvanceFocusTests` to improve assertion clarity by replacing `Assert.True`/`Assert.False` with `Assert.Equal`. Enhanced test documentation with detailed view hierarchy comments for better readability. Added a new test case, `FocusNavigation_Should_Cycle_Back_To_Top_Level_Views`, which exposes a bug in focus navigation logic where focus does not cycle back to top-level views after traversing nested views. Updated existing tests to ensure consistent handling of `TabBehavior` and made minor adjustments for improved validation of focus navigation logic. * Remove all tests for RadioGroup component The `RadioGroupTests.cs` file has been completely cleared of all test cases and associated code. This includes the removal of unit tests that validated the `RadioGroup` component's functionality, behavior, and edge cases. The deleted tests covered: - Default constructor behavior and initialization. - Handling of the `SelectedItem` property, including edge cases. - Hotkey bindings and their behavior under different focus states. - Command handling for focus, selection, and acceptance. - Orientation changes and their impact on layout. - Event handling for `SelectedItemChanged`, `Selecting`, and `Accepting`. - Mouse interactions, including single-click and double-click events. This removal eliminates all automated validation for the `RadioGroup` component, leaving it untested and increasing the risk of regressions or undetected issues in future changes. * Fix unix and fake fluent tests. * More fixes for unix and fake drivers * Change classes names for more consistency * Fix typos in docs and method signature Updated XML documentation in `FakeConsole.cs` to replace `<see cref="FakeDriver"/>` with `<exception cref="FakeDriver"></exception>` for clarity. Corrected a parameter name in `WindowsOutput.cs`'s `WriteConsole` method from `numberOfCharsToWritten` to `numberOfCharsToWrite` to fix a typo and improve readability. * Refactor: Replace RadioGroup with OptionSelector Replaced all instances of `RadioGroup` with `OptionSelector` across the codebase to standardize the control for mutually exclusive options. Updated associated properties, methods, and event handlers to align with the `OptionSelector` API, including replacing `RadioLabels` with `AssignHotKeys` and `SelectedItemChanged` with `ValueChanged`. Removed the `RadioGroup` class, marking it as obsolete. Updated documentation, comments, and test cases to reflect the new control. Adjusted layout and positioning logic in various scenarios to ensure UI consistency. Refactored scenarios such as `Buttons`, `ColorPickers`, `DynamicMenuBar`, `FileDialogExamples`, `Images`, `PosAlignDemo`, `ProgressBarStyles`, `RegionScenario`, `Themes`, and others to use `OptionSelector`. Updated `Glyphs` and `View` classes to reflect the terminology change. Cleaned up redundant code and ensured compatibility across the application. * Refactor OptionSelector to use Value instead of SelectedItem Replaced the SelectedItem property with a nullable Value property across the codebase to simplify the API and improve consistency. Updated event handlers from SelectedItemChanged to ValueChanged and adjusted logic accordingly. Refactored UI scenarios (e.g., Buttons, CharacterMap, ColorPickers) and dependent classes (e.g., BorderEditor, DimEditor, PosEditor) to use the new Value property. Improved null handling and streamlined initialization of controls. Updated tests to validate the Value property and renamed test methods for clarity. Removed the RegionOpSelector class as it was no longer needed. Performed general code cleanup, including formatting and removal of redundant code. * Refactor OptionSelector: Replace RadioLabels with Labels Updated the `OptionSelector` class and its derived classes to replace the `RadioLabels` property with a more generic `Labels` property, aligning with the base class `SelectorBase`. This change standardizes the API and simplifies label-related functionality. Refactored all instances of `RadioLabels` across the codebase, including property assignments, method calls, and references in scenarios, tests, and examples. Updated classes include `ColorPickers`, `Dialogs`, `DimAutoDemo`, `DynamicMenuBar`, `FileDialogExamples`, `Images`, `PosAlignDemo`, `Selectors`, `Shortcuts`, `TextAlignmentAndDirection`, `Themes`, `UnicodeInMenu`, `Wizards`, `UICatalogTop`, and `ScenarioTests`. Modified `OptionSelector<TEnum>` to initialize `Labels` directly using `Enum.GetValues<TEnum>()`. Removed the `RadioLabels` property from `OptionSelector`, consolidating functionality under `Labels`. Verified functionality through updated tests and scenarios to ensure consistent behavior with the previous implementation. * Refactor: Replace "radio group" with "option selector" Updated terminology across multiple classes to replace "radio group" with "option selector" for improved clarity and consistency. - Removed unused `OptionSelector` in `ColorPickers`. - Renamed `Title` in `DimAutoDemo` to "Options" and updated `BorderStyle`. - Replaced `_radioItems` with `_optionLabels` in `DimEditor` and `PosEditor`. - Renamed `styleRadioGroup` to `styleOptionSelector` in `MessageBoxes`. - Renamed `radioGroup` to `optionSelector` in `UnicodeInMenu` and `OrientationTests`. - Adjusted related references, event handlers, and UI properties. These changes align the codebase with updated terminology and improve readability. * Replace RadioGroup with OptionSelector and update docs The `RadioGroup` control has been replaced or renamed to `OptionSelector`. Documentation has been updated to reflect this change, including the behavior of raising the `Selecting` event when an option is selected. The navigation table now describes `OptionSelector` as supporting multiple options with actions like `Advance`, `SetValue+OnAccept`, and `Focus+SetValue`. A new section introduces the `OptionSelector` view, which displays mutually-exclusive items with hotkeys. Enhancements to `Menuv2` and `MenuBarv2` include setting focus on `MenuItemv2` selections and raising the `SelectedMenuItemChanged` event. Additionally, a progress bar view has been introduced to visually indicate activity progress. * Fixed `EndAfterFirstIteration` Renamed the `EndAfterFirstIteration` property to `StopAfterFirstIteration` across the codebase for improved clarity and consistency. Updated all references in the `Application`, `ApplicationImpl`, `IApplication`, and `ITimedEvents` classes, as well as related tests and documentation. Modified the application loop logic to use `StopAfterFirstIteration` for controlling the termination of the application after the first iteration. Set its default value to `false`. Updated test cases, demo applications, and XML documentation to reflect the new property name. Added a new project, `OutputView`, to the solution with appropriate configuration entries. Performed minor code cleanup to ensure consistency in naming and behavior. * Enhance selectors and clean up documentation - Added `args.Handled = true` to `CheckBox` event handlers in `FlagSelector` and `OptionSelector` to mark events as handled. - Introduced `_value` field in `FlagSelector` and added a `Cycle` method in `OptionSelector` for better value management. - Updated `OptionSelector` documentation to reference `OptionSelector<TEnum>` for type-safe enum usage. - Improved `UpdateChecked` method documentation in `OptionSelector` to clarify exception behavior. - Enabled nullable reference types in `FlagSelectorTests` and `SelectorBaseTests` and moved them to a new namespace. - Removed outdated auto-generated content from `views.md`. - Removed `CheckBox.DefaultHighlightStyle` from the default theme configuration in `OutputView.cs`. * Update event handling and expand UI documentation Modified `args.Handled` in `FlagSelector` and `OptionSelector` to allow `Accepting` event propagation, improving event handling behavior. Added comments to clarify the changes. Expanded `views.md` with detailed documentation for built-in views and controls in *Terminal.Gui*, including descriptions, examples, and rendered outputs for components like `Bar`, `Button`, `CheckBox`, and more. This update enhances developer guidance for building terminal-based UIs. * Fixed `EndAfterFirstIteration` in `ApplicationImpl` Renamed the `EndAfterFirstIteration` property to `StopAfterFirstIteration` across the codebase for improved clarity. Updated its implementation to use a getter and setter that interact with the `ApplicationImpl.Instance` singleton for centralized management. Modified the `RunLoop` method to check the new `StopAfterFirstIteration` property. Updated the default value to `false` in the `Application` class. Added a private `_stopAfterFirstIteration` field and a corresponding public property in the `ApplicationImpl` class. Updated the `Run` method in `ApplicationImpl` to stop after the first iteration if the property is set to `true`, with appropriate logging. Updated the `IApplication` interface to include the `StopAfterFirstIteration` property and clarified the behavior of the `RequestStop` method. Revised XML documentation comments to reflect these changes. * Fixed EndfterFirstIteration in ApplicaitonImpl Refactored `StopAfterFirstIteration` in `ApplicationImpl` to use an auto-property for simplicity. Updated `RunIteration` to call `view.RequestStop()` instead of modifying `view.Running`. Replaced references to `Application.EndAfterFirstIteration` with `Application.StopAfterFirstIteration` across the codebase, including `ITimedEvents`, `ApplicationTests`, and `GlobalTestSetup`. Added a new test, `InitRunShutdown_StopAfterFirstIteration_Stops`, to verify the application stops correctly after the first iteration. Updated related documentation and assertions for consistency. * Refactor Value handling and improve type safety Refactored `Value` handling across multiple classes to use nullable generic types, improving type safety and eliminating unnecessary casting. Simplified `ValueChanged` event handlers with concise lambda expressions. Enhanced `FlagSelector<TFlagsEnum>` and `OptionSelector<TEnum>` with generic `ValueChanged` events and type-safe event handling. Added nullable reference type annotations to align with modern C# practices. Improved test code by using null-forgiving operators and more descriptive assertions. Cleaned up redundant code and ensured consistency in `Value` handling. Updated `FlagSelectorTests` and `SelectorBaseTests` for better readability and maintainability. Added the `System` namespace to `FlagSelectorTEnum.cs` for compatibility. Overall, these changes enhance code readability, maintainability, and robustness. * Merged v2_develop * Update README badges for v2_develop branch Updated the `.NET Core` badge to reference the `v2_develop` branch. Adjusted the `codecov` badge to remove branch-specific paths and added a token parameter. Reorganized the `codecov` badge position in the README. Retained other badges without modification. * codcov2 * fixed pos tests * Improve cleanup, coverage config, and SpinnerStyle tests Enhanced resource cleanup in `Pos.CombineTests.cs` by disposing of `Application.Top` to prevent leaks. Updated `codecov.yml` to focus coverage on `Terminal.Gui`, simplified path patterns, and clarified configurations. Added `SpinnerStyleTests` with extensive unit tests for `SpinnerStyle` and its variants, covering default properties, behaviors, edge cases, and immutability. Organized tests for readability and ensured thorough validation of all spinner styles. Enabled nullable reference types for improved safety. * Remove .NET Core badge; add comprehensive boundary tests The `.NET Core` workflow badge was removed from the `README.md` file. Added a comprehensive suite of unit tests for the `Region.DrawOuterBoundary` method in `DrawOuterBoundaryTests.cs`. These tests validate the method's behavior across various scenarios, including: - Intersected, unioned, and complex shapes. - Edge cases like empty regions, zero-width/height rectangles, and single-pixel rectangles. - Specific shapes such as L-shaped, T-shaped, and hollow rectangles. - Overlapping, adjacent, and separate rectangles. - Thread safety with parallel drawing. - Different line styles, custom attributes, and very large regions. - Various positions, sizes, and multiple calls on the same canvas. The tests use the `Xunit` framework and include both `[Fact]` and `[Theory]` test cases. These changes enhance the codebase's robustness and ensure correctness in a wide range of scenarios. --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: BDisp <bd.bdisp@gmail.com>
566 lines
24 KiB
Markdown
566 lines
24 KiB
Markdown
# Navigation Deep Dive
|
|
|
|
This document covers Terminal.Gui's navigation system, which determines:
|
|
|
|
- What are the visual cues that help the user know which element of an application is receiving keyboard and mouse input (which one has focus)?
|
|
- How does the user change which element of an application has focus?
|
|
- What are the visual cues that help the user know what keystrokes will change the focus?
|
|
- What are the visual cues that help the user know what keystrokes will cause action in elements of the application that don't currently have focus?
|
|
- What is the order in which UI elements are traversed when using keyboard navigation?
|
|
- What are the default actions for standard key/mouse input (e.g. Hotkey, `Space`, `Enter`, `MouseClick`)?
|
|
|
|
## See Also
|
|
|
|
* [Keyboard Deep Dive](keyboard.md)
|
|
* [Mouse Deep Dive](mouse.md)
|
|
* [Lexicon & Taxonomy](lexicon.md)
|
|
|
|
## Lexicon & Taxonomy
|
|
|
|
[!INCLUDE [Navigation Lexicon](~/includes/navigation-lexicon.md)]
|
|
|
|
## Tenets for Terminal.Gui UI Navigation (Unless you know better ones...)
|
|
|
|
See the [Keyboard Tenets](keyboard.md) as they apply as well.
|
|
|
|
Tenets higher in the list have precedence over tenets lower in the list.
|
|
|
|
* **One Focus Per App** - It should not be possible to have two views be the "most focused" view in an application. There is always exactly one view that is the target of keyboard input.
|
|
|
|
* **There's Always a Way With The Keyboard** - The framework strives to ensure users wanting to use the keyboard can't get into a situation where some element of the application is not accessible via the keyboard. For example, we have unit tests that ensure built-in Views will all have at least one navigation key that advances focus. Another example: As long as a View with a HotKey is visible and enabled, regardless of view-hierarchy, if the user presses that hotkey, the action defined by the hotkey will happen (and, by default the View that defines it will be focused).
|
|
|
|
* **Flexible Overrides** - The framework makes it easy for navigation changes to be made from code and enables changing of behavior to be done in flexible ways. For example a view can be prevented from getting focus by setting `CanFocus` to `false` or overriding `OnHasFocusChanging` and returning `true` to cancel.
|
|
|
|
* **Decouple Concepts** - In v1 `CanFocus` is tightly coupled with `HasFocus`, `TabIndex`, `TabIndexes`, and `TabStop` and vice-versa. There was a bunch of "magic" logic that automatically attempted to keep these concepts aligned. This resulted in a poorly specified, hard-to-test, and fragile API. In v2 we strive to keep the related navigation concepts decoupled. For example, `CanFocus` and `TabStop` are decoupled. A view with `CanFocus == true` can have `TabStop == NoStop` and still be focusable with the mouse.
|
|
|
|
## Answering the Key Navigation Questions
|
|
|
|
### Visual Cues for Focus
|
|
|
|
**Current Focus Indicator:**
|
|
- Views with focus are rendered using their `ColorScheme.Focus` attribute
|
|
- The focused view may display a cursor (for text input views)
|
|
- Views in the focus chain (SuperViews of the focused view) also use focused styling
|
|
|
|
**Navigation Cues:**
|
|
- HotKeys are indicated by underlined characters in Labels, Buttons, and MenuItems
|
|
- Tab order is generally left-to-right, top-to-bottom within containers
|
|
- Focus indicators (such as highlight rectangles) show which view will receive input
|
|
|
|
### Changing Focus
|
|
|
|
**Keyboard Methods:**
|
|
- `Tab` / `Shift+Tab` - Navigate between TabStop views
|
|
- `F6` / `Shift+F6` - Navigate between TabGroup containers
|
|
- Arrow keys - Navigate within containers or between adjacent views
|
|
- HotKeys - Direct navigation to specific views (Alt+letter combinations)
|
|
- `Enter` / `Space` - Activate the focused view
|
|
|
|
**Mouse Methods:**
|
|
- Click on any focusable view to give it focus
|
|
- Focus behavior depends on whether the view was previously focused (RestoreFocus vs AdvanceFocus)
|
|
|
|
### Navigation Order
|
|
|
|
Views are traversed based on their `TabStop` behavior and position in the view hierarchy:
|
|
|
|
1. **TabStop Views** - Navigated with Tab/Shift+Tab in layout order
|
|
2. **TabGroup Views** - Containers navigated with F6/Shift+F6
|
|
3. **NoStop Views** - Skipped during keyboard navigation but can receive mouse focus
|
|
|
|
## Keyboard Navigation
|
|
|
|
The majority of the Terminal.Gui Navigation system is dedicated to enabling the keyboard to be used to navigate Views.
|
|
|
|
Terminal.Gui defines these keys for keyboard navigation:
|
|
|
|
- `Application.NextTabStopKey` (`Key.Tab`) - Navigates to the next subview that is a `TabStop` (see below). If there is no next, the first subview that is a `TabStop` will gain focus.
|
|
- `Application.PrevTabStopKey` (`Key.Tab.WithShift`) - Opposite of `Application.NextTabStopKey`.
|
|
- `Key.CursorRight` - Operates identically to `Application.NextTabStopKey`.
|
|
- `Key.CursorDown` - Operates identically to `Application.NextTabStopKey`.
|
|
- `Key.CursorLeft` - Operates identically to `Application.PrevTabStopKey`.
|
|
- `Key.CursorUp` - Operates identically to `Application.PrevTabStopKey`.
|
|
- `Application.NextTabGroupKey` (`Key.F6`) - Navigates to the next view in the view-hierarchy that is a `TabGroup` (see below). If there is no next, the first view that is a `TabGroup` will gain focus.
|
|
- `Application.PrevTabGroupKey` (`Key.F6.WithShift`) - Opposite of `Application.NextTabGroupKey`.
|
|
|
|
`F6` was chosen to match [Windows](https://learn.microsoft.com/en-us/windows/apps/design/input/keyboard-accelerators#common-keyboard-accelerators) conventions.
|
|
|
|
These keys are all registered as `KeyBindingScope.Application` key bindings by `Application`. Because application-scoped key bindings have the lowest priority, Views can override the behaviors of these keys (e.g. `TextView` overrides `Key.Tab` by default, enabling the user to enter `\t` into text). The `AllViews_AtLeastOneNavKey_Leaves` unit test ensures all built-in Views have at least one of the above keys that can advance focus.
|
|
|
|
### Navigation Examples
|
|
|
|
```csharp
|
|
// Basic focus management
|
|
var button = new Button() { Text = "Click Me", CanFocus = true, TabStop = TabBehavior.TabStop };
|
|
var textField = new TextField() { Text = "", CanFocus = true, TabStop = TabBehavior.TabStop };
|
|
|
|
// Container with group navigation
|
|
var frameView = new FrameView()
|
|
{
|
|
Title = "Options",
|
|
CanFocus = true,
|
|
TabStop = TabBehavior.TabGroup
|
|
};
|
|
|
|
// Programmatic focus control
|
|
button.SetFocus(); // Give focus to specific view
|
|
Application.Navigation.AdvanceFocus(NavigationDirection.Forward, TabBehavior.TabStop);
|
|
```
|
|
|
|
### HotKeys
|
|
|
|
See also [Keyboard](keyboard.md) where HotKey is covered more deeply...
|
|
|
|
`HotKeys` can be used to navigate across the entire application view-hierarchy. They work independently of `Focus`. This enables a user to navigate across a complex UI of nested subviews if needed (even in overlapped scenarios). An example use case is the `AllViewsTester` Scenario.
|
|
|
|
HotKeys are defined using the `HotKey` property and are activated using `Alt+` the specified key:
|
|
|
|
```csharp
|
|
var saveButton = new Button() { Text = "_Save", HotKey = Key.S };
|
|
var exitButton = new Button() { Text = "E_xit", HotKey = Key.X };
|
|
|
|
// Alt+S will activate save, Alt+X will activate exit, regardless of current focus
|
|
```
|
|
|
|
Additionally, multiple Views in an application (even within the same SuperView) can have the same HotKey.
|
|
|
|
## Mouse Navigation
|
|
|
|
Mouse-based navigation is straightforward in comparison to keyboard: If a view is focusable and the user clicks on it, it gains focus. There are some nuances, though:
|
|
|
|
- If a View is focusable, and it has focusable sub-views, what happens when a user clicks on the `Border` of the View? Which sub-view (if any) will also get focus?
|
|
|
|
- If a View is focusable, and it has focusable sub-views, what happens when a user clicks on the `ContentArea` of the View? Which sub-view (if any) will also get focus?
|
|
|
|
The answer to both questions is:
|
|
|
|
If the View was previously focused, the system keeps a record of the SubView that was previously most-focused and restores focus to that SubView (`RestoreFocus()`).
|
|
|
|
If the View was not previously focused, `AdvanceFocus()` is called to find the next appropriate focus target.
|
|
|
|
For this to work properly, there must be logic that removes the focus-cache used by `RestoreFocus()` if something changes that makes the previously-focusable view not focusable (e.g. if Visible has changed).
|
|
|
|
### Mouse Focus Examples
|
|
|
|
```csharp
|
|
// Mouse click behavior
|
|
view.MouseEvent += (sender, e) =>
|
|
{
|
|
if (e.Flags.HasFlag(MouseFlags.Button1Clicked) && view.CanFocus)
|
|
{
|
|
view.SetFocus();
|
|
e.Handled = true;
|
|
}
|
|
};
|
|
|
|
// Focus on mouse enter (optional behavior)
|
|
view.MouseEnter += (sender, e) =>
|
|
{
|
|
if (view.CanFocus && focusOnHover)
|
|
{
|
|
view.SetFocus();
|
|
}
|
|
};
|
|
```
|
|
|
|
## Application Level Navigation
|
|
|
|
At the application level, navigation is encapsulated within the @Terminal.Gui.ApplicationNavigation helper class which is publicly exposed via the @Terminal.Gui.App.Application.Navigation property.
|
|
|
|
@Terminal.Gui.App.ApplicationNavigation.GetFocused gets the most-focused View in the application. Will return `null` if there is no view with focus (an extremely rare situation). This replaces `View.MostFocused` in v1.
|
|
|
|
The @Terminal.Gui.App.ApplicationNavigation.FocusedChanged and @Terminal.Gui.App.ApplicationNavigation.FocusedChanging events are raised when the most-focused View in the application is changing or has changed. `FocusedChanged` is useful for apps that want to do something with the most-focused view (e.g. see `AdornmentsEditor`). `FocusChanging` is useful for apps that want to override what view can be focused across an entire app.
|
|
|
|
The @Terminal.Gui.App.ApplicationNavigation.AdvanceFocus method causes the focus to advance (forward or backwards) to the next View in the application view-hierarchy, using `behavior` as a filter.
|
|
|
|
The implementation is simple:
|
|
|
|
```cs
|
|
return Application.Current?.AdvanceFocus (direction, behavior);
|
|
```
|
|
|
|
This method is called from the `Command` handlers bound to the application-scoped keybindings created during `Application.Init`. It is `public` as a convenience.
|
|
|
|
This method replaces about a dozen functions in v1 (scattered across `Application` and `Toplevel`).
|
|
|
|
### Application Navigation Examples
|
|
|
|
```csharp
|
|
// Listen for global focus changes
|
|
Application.Navigation.FocusedChanged += (sender, e) =>
|
|
{
|
|
var focused = Application.Navigation.GetFocused();
|
|
StatusBar.Text = $"Focused: {focused?.GetType().Name ?? "None"}";
|
|
};
|
|
|
|
// Prevent certain views from getting focus
|
|
Application.Navigation.FocusedChanging += (sender, e) =>
|
|
{
|
|
if (e.NewView is SomeRestrictedView)
|
|
{
|
|
e.Cancel = true; // Prevent focus change
|
|
}
|
|
};
|
|
|
|
// Programmatic navigation
|
|
Application.Navigation.AdvanceFocus(NavigationDirection.Forward, TabBehavior.TabStop);
|
|
Application.Navigation.AdvanceFocus(NavigationDirection.Backward, TabBehavior.TabGroup);
|
|
```
|
|
|
|
## View Level Navigation
|
|
|
|
@Terminal.Gui.ViewBase.View.AdvanceFocus is the primary method for developers to cause a view to gain or lose focus.
|
|
|
|
Various events are raised when a View's focus is changing. For example, @Terminal.Gui.ViewBase.View.HasFocusChanging and @Terminal.Gui.ViewBase.View.HasFocusChanged.
|
|
|
|
### View Focus Management
|
|
|
|
```csharp
|
|
// Basic focus control
|
|
public class CustomView : View
|
|
{
|
|
protected override void OnHasFocusChanging(CancelEventArgs<bool> e)
|
|
{
|
|
if (SomeCondition)
|
|
{
|
|
e.Cancel = true; // Prevent focus change
|
|
return;
|
|
}
|
|
base.OnHasFocusChanging(e);
|
|
}
|
|
|
|
protected override void OnHasFocusChanged(EventArgs<bool> e)
|
|
{
|
|
if (e.CurrentValue)
|
|
{
|
|
// View gained focus
|
|
UpdateAppearance();
|
|
}
|
|
base.OnHasFocusChanged(e);
|
|
}
|
|
}
|
|
```
|
|
|
|
## What makes a View focusable?
|
|
|
|
First, only Views that are visible and enabled can gain focus. Both `Visible` and `Enabled` must be `true` for a view to be focusable.
|
|
|
|
For visible and enabled Views, the `CanFocus` property is then used to determine whether the `View` is focusable. `CanFocus` must be `true` for a View to gain focus. However, even if `CanFocus` is `true`, other factors can prevent the view from gaining focus...
|
|
|
|
A visible, enabled, and `CanFocus == true` view can be focused if the user uses the mouse to clicks on it or if code explicitly calls `View.SetFocus()`. Of course, the view itself or some other code can cancel the focus (e.g. by overriding `OnHasFocusChanging`).
|
|
|
|
For keyboard navigation, the `TabStop` property is a filter for which views are focusable from the current most-focused. `TabStop` has no impact on mouse navigation. `TabStop` is of type `TabBehavior`.
|
|
|
|
### TabBehavior Values
|
|
|
|
* `null` - This View is still being initialized; acts as a signal to `set_CanFocus` to set `TabStop` to `TabBehavior.TabStop` as convenience for the most common use-case. Equivalent to `TabBehavior.NoStop` when determining if a view is focusable by the keyboard or not.
|
|
|
|
* `TabBehavior.NoStop` - Prevents the user from using keyboard navigation to cause view (and by definition its subviews) to gain focus. Note: The view can still be focused using code or the mouse.
|
|
|
|
* `TabBehavior.TabStop` - Indicates a View is a focusable view with no focusable subviews. `Application.Next/PrevTabStopKey` will advance ONLY through the peer-Views (`SuperView.SubViews`).
|
|
|
|
* `TabBehavior.TabGroup` - Indicates a View is a focusable container for other focusable views and enables keyboard navigation across these containers. This applies to both tiled and overlapped views. For example, `FrameView` is a simple view designed to be a visible container of other views in tiled scenarios. It has `TabStop` set to `TabBehavior.TabGroup` (and `Arrangement` set to `ViewArrangement.Fixed`). Likewise, `Window` is a simple view designed to be a visible container of other views in overlapped scenarios. It has `TabStop` set to `TabBehavior.TabGroup` (and `Arrangement` set to `ViewArrangement.Movable | ViewArrangement.Resizable | ViewArrangement.Overlapped`). `Application.Next/PrevGroupStopKey` will advance across all `TabGroup` views in the application (unless blocked by a `NoStop` SuperView).
|
|
|
|
### Focus Requirements Summary
|
|
|
|
For a view to be focusable:
|
|
|
|
1. **Visible** = `true`
|
|
2. **Enabled** = `true`
|
|
3. **CanFocus** = `true`
|
|
4. **TabStop** != `TabBehavior.NoStop` (for keyboard navigation only)
|
|
|
|
```csharp
|
|
// Example: Make a view focusable
|
|
var view = new Label()
|
|
{
|
|
Text = "Focusable Label",
|
|
Visible = true, // Must be visible
|
|
Enabled = true, // Must be enabled
|
|
CanFocus = true, // Must be able to focus
|
|
TabStop = TabBehavior.TabStop // Keyboard navigable
|
|
};
|
|
```
|
|
|
|
## How To Tell if a View has focus? And which view is the most-focused?
|
|
|
|
`View.HasFocus` indicates whether the `View` is focused or not. It is the definitive signal. If the view has no focusable SubViews then this property also indicates the view is the most-focused view in the application.
|
|
|
|
Setting this property to `true` has the same effect as calling `View.SetFocus ()`, which also means the focus may not change as a result.
|
|
|
|
If `v.HasFocus == true` then:
|
|
|
|
- All views up `v`'s superview-hierarchy must be focusable.
|
|
- All views up `v`'s superview-hierarchy will also have `HasFocus == true`.
|
|
- The deepest-subview of `v` that is focusable will also have `HasFocus == true`
|
|
|
|
In other words, `v.HasFocus == true` does not necessarily mean `v` is the most-focused view, receiving input. If it has focusable sub-views, one of those (or a further subview) will be the most-focused (`Application.Navigation.GetFocused()`).
|
|
|
|
The `private bool _hasFocus` field backs `HasFocus` and is the ultimate source of truth whether a View has focus or not.
|
|
|
|
### Focus Chain Example
|
|
|
|
```csharp
|
|
// In a hierarchy: Window -> Dialog -> Button
|
|
// If Button has focus, then:
|
|
window.HasFocus == true // Part of focus chain
|
|
dialog.HasFocus == true // Part of focus chain
|
|
button.HasFocus == true // Actually focused
|
|
|
|
// Application.Navigation.GetFocused() returns button
|
|
var mostFocused = Application.Navigation.GetFocused(); // Returns button
|
|
```
|
|
|
|
### How does a user tell?
|
|
|
|
In short: `ColorScheme.Focus` - Views in the focus chain render with focused colors.
|
|
|
|
Views use their `ColorScheme.Focus` attribute when they are part of the focus chain. This provides visual feedback about which part of the application is active.
|
|
|
|
```csharp
|
|
// Custom focus styling
|
|
protected override void OnDrawContent(Rectangle viewport)
|
|
{
|
|
var attribute = HasFocus ? GetFocusColor() : GetNormalColor();
|
|
Driver.SetAttribute(attribute);
|
|
// ... draw content
|
|
}
|
|
```
|
|
|
|
## How to make a View become focused?
|
|
|
|
The primary `public` method for developers to cause a view to get focus is `View.SetFocus()`.
|
|
|
|
Unlike v1, in v2, this method can return `false` if the focus change doesn't happen (e.g. because the view wasn't focusable, or the focus change was cancelled).
|
|
|
|
```csharp
|
|
// Programmatic focus control
|
|
if (myButton.SetFocus())
|
|
{
|
|
Console.WriteLine("Button now has focus");
|
|
}
|
|
else
|
|
{
|
|
Console.WriteLine("Could not focus button");
|
|
}
|
|
|
|
// Alternative: Set HasFocus property (same effect)
|
|
myButton.HasFocus = true;
|
|
```
|
|
|
|
## How to make a View become NOT focused?
|
|
|
|
The typical method to make a view lose focus is to have another View gain focus.
|
|
|
|
```csharp
|
|
// Focus another view to remove focus from current
|
|
otherView.SetFocus();
|
|
|
|
// Or advance focus programmatically
|
|
Application.Navigation.AdvanceFocus(NavigationDirection.Forward, TabBehavior.TabStop);
|
|
|
|
// Focus can also be lost when views become non-focusable
|
|
myView.CanFocus = false; // Will lose focus if it had it
|
|
myView.Visible = false; // Will lose focus if it had it
|
|
myView.Enabled = false; // Will lose focus if it had it
|
|
```
|
|
|
|
## Determining the Most Focused SubView
|
|
|
|
In v1 `View` had `MostFocused` property that traversed up the view-hierarchy returning the last view found with `HasFocus == true`. In v2, `Application.Navigation.GetFocused()` provides the same functionality with less overhead.
|
|
|
|
```csharp
|
|
// v2 way to get the most focused view
|
|
var focused = Application.Navigation.GetFocused();
|
|
|
|
// This replaces the v1 pattern:
|
|
// var focused = Application.Top.MostFocused;
|
|
```
|
|
|
|
## How Does `View.Add/Remove` Work?
|
|
|
|
In v1, calling `super.Add (view)` where `view.CanFocus == true` caused all views up the hierarchy (all SuperViews) to get `CanFocus` set to `true` as well.
|
|
|
|
Also, in v1, if `view.CanFocus == true`, `Add` would automatically set `TabStop`.
|
|
|
|
In v2, developers need to explicitly set `CanFocus` for any view in the view-hierarchy where focus is desired. This simplifies the implementation significantly and removes confusing behavior.
|
|
|
|
In v2, the automatic setting of `TabStop` in `Add` is retained because it is not overly complex to do so and is a nice convenience for developers to not have to set both `TabStop` and `CanFocus`. Note we do NOT automatically change `CanFocus` if `TabStop` is changed.
|
|
|
|
```csharp
|
|
// v2 explicit focus setup
|
|
var container = new FrameView()
|
|
{
|
|
Title = "Container",
|
|
CanFocus = true, // Must be explicitly set
|
|
TabStop = TabBehavior.TabGroup
|
|
};
|
|
|
|
var button = new Button()
|
|
{
|
|
Text = "Click Me",
|
|
CanFocus = true, // Must be explicitly set
|
|
TabStop = TabBehavior.TabStop // Set automatically by Add(), but can override
|
|
};
|
|
|
|
container.Add(button); // Does not automatically set CanFocus on container
|
|
```
|
|
|
|
## Knowing When a View's Focus is Changing
|
|
|
|
@Terminal.Gui.ViewBase.View.HasFocusChanging and @Terminal.Gui.ViewBase.View.HasFocusChanged are raised when a View's focus is changing.
|
|
|
|
```csharp
|
|
// Monitor focus changes
|
|
view.HasFocusChanging += (sender, e) =>
|
|
{
|
|
if (e.NewValue && !ValidateCanFocus())
|
|
{
|
|
e.Cancel = true; // Prevent gaining focus
|
|
}
|
|
};
|
|
|
|
view.HasFocusChanged += (sender, e) =>
|
|
{
|
|
if (e.CurrentValue)
|
|
{
|
|
OnViewGainedFocus();
|
|
}
|
|
else
|
|
{
|
|
OnViewLostFocus();
|
|
}
|
|
};
|
|
```
|
|
|
|
## Built-In Views Interactivity
|
|
|
|
The following table summarizes how built-in views respond to various input methods:
|
|
|
|
| View | States | Static | Default | HotKeys | Select Cmd | Accept Cmd | HotKey Cmd | Click Focus | DblClick | RightClick | GrabMouse |
|
|
|------|--------|--------|---------|---------|------------|------------|------------|-------------|----------|------------|-----------|
|
|
| **View** | 1 | Yes | No | 1 | OnSelect | OnAccept | Focus | Focus | - | - | No |
|
|
| **Label** | 1 | Yes | No | 1 | OnSelect | OnAccept | FocusNext | Focus | - | FocusNext | No |
|
|
| **Button** | 1 | No | Yes | 1 | OnSelect | Focus+OnAccept | Focus+OnAccept | HotKey | - | Select | No |
|
|
| **CheckBox** | 3 | No | No | 1 | OnSelect+Advance | OnAccept | OnAccept | Select | - | Select | No |
|
|
| **OptionSelector** | >1 | No | No | 2+ | Advance | SetValue+OnAccept | Focus+SetValue | SetFocus+SetCursor | - | SetFocus+SetCursor | No |
|
|
| **Slider** | >1 | No | No | 1 | SetFocusedOption | SetFocusedOption+OnAccept | Focus | SetFocus+SetOption | - | SetFocus+SetOption | Yes |
|
|
| **ListView** | >1 | No | No | 1 | MarkUnMarkRow | OpenSelected+OnAccept | OnAccept | SetMark+OnSelectedChanged | OpenSelected+OnAccept | - | No |
|
|
| **TextField** | 1 | No | No | 1 | - | OnAccept | Focus | Focus | SelectAll | ContextMenu | No |
|
|
| **TextView** | 1 | No | No | 1 | - | OnAccept | Focus | Focus | - | ContextMenu | Yes |
|
|
|
|
### Table Legend
|
|
|
|
- **States**: Number of visual/functional states the view can have
|
|
- **Static**: Whether the view is primarily for display (non-interactive)
|
|
- **Default**: Whether the view can be a default button (activated by Enter)
|
|
- **HotKeys**: Number of hotkeys the view typically supports
|
|
- **Select Cmd**: What happens when Command.Select is invoked
|
|
- **Accept Cmd**: What happens when Command.Accept is invoked
|
|
- **HotKey Cmd**: What happens when the view's hotkey is pressed
|
|
- **Click Focus**: Behavior when clicked (if CanFocus=true)
|
|
- **DblClick**: Behavior on double-click
|
|
- **RightClick**: Behavior on right-click
|
|
- **GrabMouse**: Whether the view captures mouse for drag operations
|
|
|
|
## Common Navigation Patterns
|
|
|
|
### Dialog Navigation
|
|
|
|
```csharp
|
|
var dialog = new Dialog()
|
|
{
|
|
Title = "Settings",
|
|
CanFocus = true,
|
|
TabStop = TabBehavior.TabGroup
|
|
};
|
|
|
|
var okButton = new Button() { Text = "OK", IsDefault = true };
|
|
var cancelButton = new Button() { Text = "Cancel" };
|
|
|
|
// Tab navigates between buttons, Enter activates default
|
|
dialog.Add(okButton, cancelButton);
|
|
```
|
|
|
|
### Container Navigation
|
|
|
|
```csharp
|
|
var leftPanel = new FrameView()
|
|
{
|
|
Title = "Options",
|
|
TabStop = TabBehavior.TabGroup,
|
|
X = 0,
|
|
Width = Dim.Percent(50)
|
|
};
|
|
|
|
var rightPanel = new FrameView()
|
|
{
|
|
Title = "Preview",
|
|
TabStop = TabBehavior.TabGroup,
|
|
X = Pos.Right(leftPanel),
|
|
Width = Dim.Fill()
|
|
};
|
|
|
|
// F6 navigates between panels, Tab navigates within panels
|
|
```
|
|
|
|
### List Navigation
|
|
|
|
```csharp
|
|
var listView = new ListView()
|
|
{
|
|
CanFocus = true,
|
|
TabStop = TabBehavior.TabStop
|
|
};
|
|
|
|
// Arrow keys navigate items, Enter selects, Space toggles
|
|
listView.KeyBindings.Add(Key.CursorUp, Command.Up);
|
|
listView.KeyBindings.Add(Key.CursorDown, Command.Down);
|
|
listView.KeyBindings.Add(Key.Enter, Command.Accept);
|
|
```
|
|
|
|
## Accessibility Considerations
|
|
|
|
Terminal.Gui's navigation system is designed with accessibility in mind:
|
|
|
|
### Keyboard Accessibility
|
|
- All functionality must be accessible via keyboard
|
|
- Tab order should be logical and predictable
|
|
- HotKeys provide direct access to important functions
|
|
- Arrow keys provide fine-grained navigation within controls
|
|
|
|
### Visual Accessibility
|
|
- Focus indicators must be clearly visible
|
|
- Color is not the only indicator of focus state
|
|
- Text and background contrast meets accessibility standards
|
|
- HotKeys are visually indicated (underlined characters)
|
|
|
|
### Screen Reader Support
|
|
- Focus changes are announced through system events
|
|
- View titles and labels provide context
|
|
- Status information is available programmatically
|
|
|
|
### Best Practices for Accessible Navigation
|
|
|
|
```csharp
|
|
// Provide meaningful labels
|
|
var button = new Button() { Text = "_Save Document", HotKey = Key.S };
|
|
|
|
// Set logical tab order
|
|
container.TabStop = TabBehavior.TabGroup;
|
|
foreach (var view in container.Subviews)
|
|
{
|
|
view.TabStop = TabBehavior.TabStop;
|
|
}
|
|
|
|
// Provide keyboard alternatives to mouse actions
|
|
view.KeyBindings.Add(Key.F10, Command.Context); // Right-click equivalent
|
|
view.KeyBindings.Add(Key.Space, Command.Select); // Click equivalent
|
|
```
|
|
|
|
For more information on accessibility standards, see:
|
|
- [Web Content Accessibility Guidelines (WCAG)](https://www.w3.org/WAI/WCAG21/quickref/)
|
|
- [Microsoft Accessibility Guidelines](https://learn.microsoft.com/en-us/windows/apps/design/accessibility/)
|
|
- [.NET Accessibility Documentation](https://learn.microsoft.com/en-us/dotnet/desktop/winforms/advanced/walkthrough-creating-an-accessible-windows-based-application)
|
|
|