Files
Terminal.Gui/docfx/docs/View.md
Copilot c5906c2dc1 #4329—Major Terminal.Gui v2 Architecture Modernization: Application Decoupling, Terminology Improvements, and Nullable Migration (#4338)
* Initial plan

* Add comprehensive terminology proposal for Application.Top/Toplevel renaming

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* Add terminology proposal summary document

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* Add before/after comparison document for terminology proposal

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* Add index document for terminology proposal

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* Add Mermaid diagrams visualizing the terminology proposal

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* Move terminology docs to docfx/docs per CONTRIBUTING.md guidelines

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* Update terminology proposal to reflect recent modernization (post-MainLoop removal)

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* Update terminology proposal - validate against recent driver refactoring changes

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* Update proposal after massive v2_develop modernization - TopLevels now public, RunState→SessionToken

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* Update proposal: RunStack → SessionStack to align with SessionToken terminology

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* Phase 1: Core API rename - Application.Top→Current, TopLevels→SessionStack

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* Phase 2: Fix test compilation errors for renamed properties

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* Phase 3: Update documentation files with new terminology

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* Refactor generic type names and remove unused field

Renamed generic type parameters in `Dim` and `Pos` classes for clarity:
- `T` was renamed to `TDim` in `Dim.Has` method.
- `T` was renamed to `TPos` in `Pos.Has` method.
Updated type casting and pattern matching logic to reflect these changes.

Removed the unused `_stopAfterFirstIteration` field from the `ApplicationImpl` class to clean up the codebase.

* Increase minimum code coverage target to 75%

Updated the `codecov.yml` configuration file to raise the
`project.default.target` value from 70% to 75%, enforcing
stricter code coverage requirements for the overall project.

* Add comprehensive unit tests for ApplicationImpl Begin/End logic

Added ApplicationImplBeginEndTests with 16 tests covering:
- Begin/End argument validation
- SessionStack push/pop operations
- Current property management
- Balanced Begin/End enforcement
- Multiple nested Begin/End scenarios
- ResetState cleanup behavior
- Toplevel activation/deactivation
- SessionToken management

Tests validate the fragile state management logic in ApplicationImpl.Lifecycle.cs
and ApplicationImpl.Run.cs to catch regressions in Current/SessionStack handling.

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* Refactor ApplicationImplBeginEndTests to work with ApplicationImpl instances directly

Tests now:
- Create ApplicationImpl instances directly instead of using global Application
- Use try-finally blocks to ensure Shutdown() is always called
- Work with app.Init() and app.Shutdown() properly
- 13 of 16 tests passing (3 tests need adjustment for ResetState behavior)

Tests validate fragile Begin/End state management logic without polluting global Application state.

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* Fix ApplicationImplBeginEndTests: Remove explicit ResetState calls, rely on Shutdown

Per maintainer feedback:
- Tests should not call ResetState explicitly if they call Shutdown (Shutdown calls ResetState)
- Removed all explicit app.ResetState() calls from tests
- Tests now only call Shutdown in finally blocks for cleanup
- Ensured toplevels are disposed BEFORE Shutdown to satisfy DEBUG_IDISPOSABLE assertions
- Fixed test cleanup order to prevent ResetState assertion failures
- All 16 tests now pass successfully

ResetState is idempotent - the issue was tests calling it unnecessarily and with incorrect disposal ordering.

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* Phase 1: Enable nullable by default, add directives to all files

- Added <Nullable>enable</Nullable> to Terminal.Gui.csproj
- Removed #nullable enable from 37 files (now redundant with project setting)
- Added #nullable disable to 170 files that don't have nullable enabled yet
- Build successful with 279 nullable warnings (expected)

Breakdown of files with #nullable disable:
- 27 in Views/ directory (will remain disabled per plan)
- 143 outside Views/ (need to be fixed in subsequent commits)

Next: Systematically fix nullable issues in non-View files.

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* Phase 2: Remove nullable disable from all non-View files - COMPLETE!

- Removed #nullable disable from 142 non-View files
- All non-View code is now nullable-enabled
- Build successful with 0 errors, only 1 unrelated warning
- Created NULLABLE_VIEWS_REMAINING.md documenting the 121 View files still with nullable disable

Nullable cleanup summary:
 App/: 25 files - nullable enabled
 Configuration/: 24 files - nullable enabled
 ViewBase/: 30 files - nullable enabled
 Drivers/: 25 files - nullable enabled
 Drawing/: 18 files - nullable enabled
 FileServices/: 7 files - nullable enabled
 Input/: 6 files - nullable enabled
 Text/: 5 files - nullable enabled
 Resources/: 3 files - nullable enabled
⏸️  Views/: 121 files - remain disabled (as requested)

Total: 143 files nullable-enabled, 121 View files remain disabled.

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* WIP: fixing nullability issues.

* Fixed final nullability issues.

* Moved Arrangment tests

* Refactor and improve modularity across multiple classes

Refactored `FillRectangles` in `RegionScenario` and `Region` to accept an `IDriver` parameter, reducing reliance on global state. Updated `ApplicationImpl` to replace static method calls with instance methods for better encapsulation. Renamed `Toplevel` to `Current` in `IPopover` and related classes for clarity.

Simplified `LineCanvas` methods by removing unnecessary `IDriver` parameters. Added `Id` and `App` properties to `View` for better state management and unique identification. Streamlined the `Driver` property in `View` with a concise getter.

Improved formatting and consistency across files, including `Region` and `IntersectionRuneResolver`. Enhanced thread safety in `Region` and cleaned up redundant code. Updated tests to align with interface changes and ensure compatibility.

* Refactor to make IDriver dependency explicit

Updated `AnsiEscapeSequenceRequest.Send` to accept an `IDriver?` parameter, replacing reliance on `Application.Driver`. Refactored `AnsiRequestScheduler` methods (`SendOrSchedule`, `RunSchedule`, and private `Send`) to propagate the `IDriver?` parameter, ensuring explicit driver dependency.

Modified `DriverImpl.QueueAnsiRequest` to pass `this` to `SendOrSchedule`. Updated `AnsiRequestSchedulerTests` to reflect new method signatures, passing `null` for the driver parameter where applicable.

Added `<param>` documentation for new parameters to improve clarity. These changes enhance flexibility, maintainability, and testability by reducing reliance on global state and allowing driver substitution in tests.

* WIP: Started migrating to View.App

Refactored `ApplicationImpl` to ensure proper handling of the `App`
property for `Toplevel` instances, improving modularity. Replaced
direct references to `Application` with `App` in `Border`, `ShadowView`,
and other classes to enhance flexibility and maintainability.

Introduced `GetApp` in `View` to allow overrides for retrieving the
`App` instance. Updated `Adornment` to use this method. Moved mouse
event subscriptions in `Border` to `BeginInit` for proper lifecycle
management.

Updated unit tests in `ArrangementTests` to use `App.Mouse` instead of
`Application.Mouse`, ensuring alignment with the refactored design.
Added `BeginInit` and `EndInit` calls for proper initialization during
tests. Removed redundant code and improved test assertions.

* WIP: Next set of View.App changes

Updated `SetClipToScreen`, `SetClip`, and `GetClip` methods to accept an `IDriver` parameter, replacing reliance on the global `Application.Driver`. This improves modularity, testability, and reduces implicit global state usage.

- Updated `Driver` property in `View` to use `App?.Driver` as fallback.
- Refactored `DimAuto` to use `App?.Screen.Size` with a default for unit tests.
- Updated all test cases to align with the new method signatures.
- Performed general cleanup for consistency and readability.

* Adds View clip tests.

* Merged

* Merged

* wip

* Fixed test bug.

* Refactored Thickness.Draw to require driver.

* Made TextFormatter.Draw require driver.

* Code cleanup.

* Un did stoopid idea.

* Decouped Application.Navigation

* MASSIVE - Almost completely decoupled Application from View etc...

* Obsolete

* Missed some

* More cleanup and decoupling.

Refactor `ToString` and remove legacy code

Refactored `ToString` implementations across `Application`, `DriverImpl`, and `IDriver` to improve consistency and maintainability. Removed the legacy `ToString(IDriver? driver)` method and its associated references. Simplified `ToString` in `DriverImpl` to generate a string representation of the `Contents` buffer.

Replaced redundant XML documentation with `<inheritdoc/>` tags to reduce duplication. Cleaned up unused `global using` directives and removed deprecated methods and properties, including `Screen`, `SetCursorVisibility`, and `IsRuneSupported`.

Updated test cases in `GuiTestContext` and `DriverAssert` to use the new `ToString` implementation. Improved error messages for better debugging output. Streamlined LINQ queries and removed redundant checks for better readability and performance.

Enhanced maintainability by decluttering the codebase, aligning namespaces, and consolidating related changes.

* Changes before error encountered

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* Update docfx/docs to document View.App architecture and instance-based patterns

Updated 16 documentation files to reflect the major architectural changes:

NEW FILES:
- application.md: Comprehensive deep dive on decoupled Application architecture

UPDATED FILES:
- View.md: Documents View.App property, GetApp(), and instance-based patterns
- navigation.md: Shows View.App usage instead of static Application
- drivers.md: Documents View.Driver and GetDriver() patterns
- keyboard.md: Event handling through View.App
- mouse.md: Mouse event handling via View.App
- arrangement.md: Updated code examples to use View.App
- drawing.md: Rendering examples with instance-based API
- cursor.md: Cursor management through View.App
- multitasking.md: SessionStack and session management via View.App
- Popovers.md: Popover patterns with View.App
- cancellable-work-pattern.md: Updated examples
- command.md: Command pattern with View.App context
- config.md: Configuration access through View.App
- migratingfromv1.md: Migration guide for static→instance patterns
- newinv2.md: Documents new instance-based architecture

All code examples now demonstrate the instance-based API (view.App.Current)
instead of obsolete static Application references. Documentation accurately
reflects the massive architectural decoupling achieved in this PR.

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* Add `ToAnsi` support for ANSI escape sequence generation

Introduced `ToAnsi` in `IDriver` and `IOutput` interfaces to generate
ANSI escape sequences representing the terminal's current state. This
enables serialization of terminal content for debugging, testing, and
exporting.

Implemented `ToAnsi` in `DriverImpl` and `FakeOutput`, supporting both
16-color and RGB modes. Refactored `OutputBase` with helper methods
`BuildAnsiForRegion` and `AppendCellAnsi` for efficient ANSI generation.

Enhanced `GuiTestContext` with `AnsiScreenShot` for capturing terminal
state during tests. Added `ToAnsiTests` for comprehensive validation,
including edge cases, performance, and wide/Unicode character handling.

Updated documentation to reflect `ToAnsi` functionality and modernized
driver architecture. Improved testability, modularity, and performance
while removing legacy driver references.

* Improve null safety and cleanup in GuiTestContext

Enhanced null safety across `GuiTestContext` and `GuiTestContextTests`:
- Replaced `a` with `app` for better readability in tests.
- Added null checks (`!`, `?.`) to prevent potential null reference exceptions.
- Removed redundant `WaitIteration` and duplicate `ScreenShot` calls.

Improved error handling and robustness:
- Updated shutdown logic to use null-safe calls for `RequestStop` and `Shutdown`.
- Applied null-safe invocation for `_applicationImpl.Invoke`.

General cleanup:
- Removed redundant method calls and improved naming consistency.
- Ensured better maintainability and adherence to best practices.

* Refactor docs: remove deprecated files, update architecture

Removed outdated documentation files related to the terminology
proposal (`terminology-before-after.md`, `terminology-diagrams.md`,
`terminology-index.md`, `terminology-proposal-summary.md`,
`terminology-proposal.md`) from the `Docs` project. These files
were either deprecated or consolidated into other documentation.

Updated `application.md`:
- Added a "View Hierarchy and Run Stack" section with a Mermaid
  diagram to illustrate the relationship between the view hierarchy
  and the application session stack.
- Added a "Usage Example Flow" section with a sequence diagram
  to demonstrate the flow of running and stopping views.

These changes improve clarity, streamline documentation, and
align with the finalized terminology updates for the
`Application.Current` and `Application.SessionStack` APIs.

* Refactor Init/Run methods to simplify driver handling

The `Init` method in `Application` and `IApplication` now accepts only an optional `driverName` parameter, removing the `IDriver` parameter. This simplifies initialization by relying on driver names to determine the appropriate driver.

The `Run` methods have been updated to use `driverName` instead of `driver`, ensuring consistency with the updated `Init` method.

Replaced redundant inline documentation with `<inheritdoc>` tags to improve maintainability and consistency. Legacy `Application` methods (`Init`, `Shutdown`, `Run`) have been marked as `[Obsolete]` to signal their eventual deprecation.

Test cases have been refactored to align with the updated `Init` method signature, removing unused `driver` parameters. Documentation files have also been updated to reflect these API changes.

These changes improve clarity, reduce complexity, and ensure a more consistent API design.

* Refactor: Introduce Application.Create() factory method

Introduced a new static method `Application.Create()` to create
instances of `IApplication`, replacing direct instantiation of
`ApplicationImpl`. This enforces a cleaner, recommended pattern
for creating application instances.

Made the `ApplicationImpl` constructor `internal` to ensure
`Application.Create()` is used for instance creation.

Refactored test cases across multiple files to use
`Application.Create()` instead of directly instantiating
`ApplicationImpl`. Simplified object initialization in tests
using target-typed `new()` expressions.

Updated documentation and examples in `application.md` to
reflect the new instance-based architecture and highlight its
benefits, such as supporting multiple applications with
different drivers.

Improved code readability, formatting, and consistency in
tests and documentation. Aligned `ApplicationImplBeginEndTests`
to use `IApplication` directly, adhering to the new architecture.

* Added `Application.StopAll` and fixed coupling issues.

Refactored `ApplicationImpl` to use an instance-based approach, replacing the static singleton pattern and Lazy<T>. Introduced `SetInstance` for configuring the singleton instance and updated tests to use `ApplicationImpl.Instance` or explicitly set the `Driver` property.

Enabled nullable reference types across the codebase, updating fields and variables to nullable types where applicable. Added null checks to improve safety and prevent runtime errors.

Refactored timeout management by introducing tokens for `Application.AddTimeout` and adding a `StopAll` method to `TimedEvents` for cleanup. Updated tests to use `System.Threading.Timer` for independent watchdog timers.

Removed legacy code, improved logging for error cases, and updated view initialization to explicitly set `App` or `Driver` in tests. Enhanced test coverage and restructured `ScrollSliderTests` for better readability.

Performed general code cleanup, including formatting changes, removal of unused imports, and improved naming consistency.

* Refactor: Transition to IApplication interface

Refactored the codebase to replace the static `Application` class with the `IApplication` interface, improving modularity, testability, and maintainability. Updated methods like `Application.Run`, `RequestStop`, and `Init` to use the new interface.

Marked static members `SessionStack` and `Current` as `[Obsolete]` and delegated their functionality to `ApplicationImpl.Instance`. Updated XML documentation to reflect these changes.

Simplified code by removing redundant comments, unused code, and converting methods like `GetMarginThickness` to single-line expressions. Improved null safety with null-conditional operators in `ToplevelTransitionManager`.

Enhanced consistency with formatting updates, logging improvements, and better error handling. Updated `Shortcut` and other classes to align with the new interface-based design.

Made breaking changes, including the removal of the `helpText` parameter in the `Shortcut` constructor. Updated `Wizard`, `Dialog`, and `GraphView` to use `IApplication` methods. Adjusted `ViewportSettings` and `HighlightStates` for better behavior.

* Enhance null-safety and simplify codebase

Improved null-safety by adopting nullable reference types and adding null-forgiving operators (`!`) where appropriate. Replaced direct method calls with null-safe calls using the null-conditional operator (`?.`) to prevent potential `NullReferenceException`.

Removed default parameter values in test methods to enforce explicit parameter passing. Refactored test classes to remove unnecessary dependencies on `ITestOutputHelper`.

Fixed a bug in `WindowsOutput.cs` by setting `_force16Colors` to `false` to avoid reliance on a problematic driver property. Updated `SessionTokenTests` to use null-forgiving operators for clarity in intentional null usage.

Simplified graph and UI updates by ensuring safe access to properties and methods. Cleaned up namespaces and removed unused `using` directives for better readability.

Updated `Dispose` methods to use null-safe calls and replaced nullable driver initialization with non-nullable initialization in `ScrollSliderTests` to ensure proper instantiation.

* Refactor test code to use nullable `App` property

Replaced direct `Application` references with `App` property across test classes to improve encapsulation and robustness. Updated `GuiTestContext` to use a nullable `App` property, replacing `_applicationImpl` for consistency.

Refactored key event handling to use `App.Driver` and revised `InitializeApplication` and `CleanupApplication` methods to ensure safe usage of the nullable `App` property. Updated `Then` callbacks to explicitly pass `App` for clarity.

Replaced `Application.QuitKey` with `context.App?.Keyboard.RaiseKeyDownEvent` to ensure context-specific event handling. Refactored `EnableForDesign` logic in `MenuBarv2Tests` and `PopoverMenuTests` to operate on the correct application instance.

Improved null safety in test assertions and revised `RequestStop` and `Shutdown` calls to use `App?.RequestStop` and `App?.Shutdown`. Updated navigation logic to use `Terminal.Gui.App.Application` for namespace consistency.

Enhanced exception handling in the `Invoke` method and performed general cleanup to align with modern C# practices, improving maintainability and readability.

* Commented out exception handling in Application.Shutdown

The `try-catch` block around `Application.Shutdown` was commented out, disabling the logging of exceptions thrown after a test exited. This change removes the `catch` block that used `Debug.WriteLine` for logging.

The `finally` block remains intact, ensuring cleanup operations such as clearing `View.Instances` and resetting the application state are still executed.

* Fixes #4394 - Changing Theme at Runtime does not Update Some Properties

* Tweaks to config format.

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: Tig <tig@users.noreply.github.com>
Co-authored-by: tig <585482+tig@users.noreply.github.com>
2025-11-19 16:23:35 -05:00

27 KiB

View Deep Dive

View is the base class for all visible UI elements in Terminal.Gui. View provides core functionality for layout, drawing, input handling, navigation, and scrolling. All interactive controls, windows, and dialogs derive from View.

See the Views Overview for a catalog of all built-in View subclasses.

Table of Contents


View Hierarchy

Terminology

  • View - The base class for all visible UI elements
  • SubView - A View that is contained in another View and rendered as part of the containing View's content area. SubViews are added via View.Add
  • SuperView - The View that contains SubViews. Each View has a View.SuperView property that references its container
  • Child View - A view that holds a reference to another view in a parent/child relationship (used sparingly; generally SubView/SuperView is preferred)
  • Parent View - A view that holds a reference to another view but is NOT a SuperView (used sparingly)

Key Properties

  • View.SubViews - Read-only list of all SubViews added to this View
  • View.SuperView - The View's container (null if the View has no container)
  • View.Id - Unique identifier for the View (should be unique among siblings)
  • View.Data - Arbitrary data attached to the View
  • View.App - The application context this View belongs to
  • View.Driver - The driver used for rendering (derived from App). This is a shortcut to App.Driver for convenience.

View Composition

Views are composed of several nested layers that define how they are positioned, drawn, and scrolled:

[!INCLUDE View Composition]

The Layers

  1. Frame - The outermost rectangle defining the View's location and size relative to the SuperView's content area
  2. Margin - Adornment that provides spacing between the View and other SubViews
  3. Border - Adornment that draws the visual border and title
  4. Padding - Adornment that provides spacing between the border and the viewport
  5. Viewport - Rectangle describing the visible portion of the content area
  6. Content Area - The total area where content can be drawn (defined by View.GetContentSize)

See the Layout Deep Dive for complete details on View composition and layout.


Core Concepts

Frame vs. Viewport

  • Frame - The View's location and size in SuperView-relative coordinates. Frame includes all adornments (Margin, Border, Padding)
  • Viewport - The visible "window" into the View's content, located inside the adornments. Viewport coordinates are always relative to (0,0) of the content area
// Frame is SuperView-relative
view.Frame = new Rectangle(10, 5, 50, 20);

// Viewport is content-relative (the visible portal)
view.Viewport = new Rectangle(0, 0, 45, 15); // Adjusted for adornments

Content Area and Scrolling

The Content Area is where the View's content is drawn. By default, the content area size matches the Viewport size. To enable scrolling:

  1. Call View.SetContentSize with a size larger than the Viewport
  2. Change Viewport.Location to scroll the content

See the Scrolling Deep Dive for complete details.

Adornments

Adornments are special Views that surround the content:

  • Margin - Transparent spacing outside the Border
  • Border - Visual frame with LineStyle, title, and arrangement UI
  • Padding - Spacing inside the Border, outside the Viewport

Each adornment has a Thickness that defines the width of each side (Top, Right, Bottom, Left).

See the Layout Deep Dive for complete details on adornments.


View Lifecycle

Initialization

Views implement ISupportInitializeNotification:

  1. Constructor - Creates the View and sets up default state
  2. BeginInit - Signals initialization is starting
  3. EndInit - Signals initialization is complete; raises View.Initialized event
  4. IsInitialized - Property indicating if initialization is complete

During initialization, View.App is set to reference the application context, enabling views to access application services like the driver and current session.

Disposal

Views are IDisposable:

  • Call View.Dispose to clean up resources
  • The View.Disposing event is raised when disposal begins
  • Automatically disposes SubViews, adornments, and scroll bars

Subsystems

View is organized as a partial class across multiple files, each handling a specific subsystem:

Commands

See the Command Deep Dive.

Input Handling

Keyboard

See the Keyboard Deep Dive.

Mouse

See the Mouse Deep Dive.

Layout and Arrangement

See the Layout Deep Dive and Arrangement Deep Dive.

Position and Size

Layout Features

Arrangement

Events

  • LayoutStarted - Before layout begins
  • LayoutComplete - After layout completes
  • FrameChanged - When Frame changes
  • ViewportChanged - When Viewport changes

Drawing

See the Drawing Deep Dive.

Color and Style

See the Scheme Deep Dive for details on color theming.

Drawing Methods

Drawing Events

  • DrawingContent - Before content is drawn
  • DrawingContentComplete - After content is drawn
  • DrawingAdornments - Before adornments are drawn
  • DrawingAdornmentsComplete - After adornments are drawn

Invalidation

Navigation

See the Navigation Deep Dive.

Events:

  • HasFocusChanging - Before focus changes (cancellable)
  • HasFocusChanged - After focus changes
  • Accepting - When Command.Accept is invoked (typically Enter key)
  • Accepted - After Command.Accept completes
  • Selecting - When Command.Select is invoked (typically Space or mouse click)
  • Selected - After Command.Select completes

Scrolling

See the Scrolling Deep Dive.

Text


View Lifecycle

1. Creation

View view = new ()
{
    X = Pos.Center(),
    Y = Pos.Center(),
    Width = Dim.Percent(50),
    Height = Dim.Fill()
};

2. Initialization

When a View is added to a SuperView or when Application.Run is called:

  1. BeginInit is called
  2. EndInit is called
  3. IsInitialized becomes true
  4. Initialized event is raised

3. Layout

Layout happens automatically when needed:

  1. View.SetNeedsLayout marks View as needing layout
  2. View.Layout calculates position and size
  3. LayoutStarted event is raised
  4. Frame and Viewport are calculated based on X, Y, Width, Height
  5. SubViews are laid out
  6. LayoutComplete event is raised

4. Drawing

Drawing happens automatically when needed:

  1. View.SetNeedsDraw marks View as needing redraw
  2. View.Draw renders the View
  3. DrawingContent event is raised
  4. View.OnDrawingContent is called (override to draw custom content)
  5. DrawingContentComplete event is raised
  6. Adornments are drawn
  7. SubViews are drawn

5. Input Processing

Input is processed in this order:

  1. Keyboard: Key → KeyBindings → Command → Command Handlers → Events
  2. Mouse: MouseEvent → MouseBindings → Command → Command Handlers → Events

6. Disposal

view.Dispose();
  • Raises View.Disposing event
  • Disposes adornments, scrollbars, SubViews
  • Cleans up event handlers and resources

Subsystems

Commands

See the Command Deep Dive for complete details.

Views use a command pattern for handling input:

// Add a command the view supports
view.AddCommand (Command.Accept, () => 
{
    // Handle the Accept command
    return true;
});

// Bind a key to the command
view.KeyBindings.Add (Key.Enter, Command.Accept);

// Bind a mouse action to the command
view.MouseBindings.Add (MouseFlags.Button1Clicked, Command.Select);

Input

Keyboard

See the Keyboard Deep Dive for complete details.

The keyboard subsystem processes key presses through:

  1. View.KeyDown event (cancellable)
  2. View.OnKeyDown virtual method
  3. View.KeyBindings - Converts keys to commands
  4. Command handlers (registered via View.AddCommand)
  5. View.KeyUp event

Mouse

See the Mouse Deep Dive for complete details.

The mouse subsystem processes mouse events through:

  1. View.MouseEvent event (low-level)
  2. View.OnMouseEvent virtual method
  3. View.MouseEnter / View.MouseLeave events
  4. View.MouseBindings - Converts mouse actions to commands
  5. Command handlers
  6. View.MouseClick event (high-level)

Layout

See the Layout Deep Dive for complete details.

Layout is declarative using Pos and Dim:

var label = new Label { Text = "Name:" };
var textField = new TextField 
{ 
    X = Pos.Right(label) + 1,
    Y = Pos.Top(label),
    Width = Dim.Fill()
};

The layout system automatically:

  • Calculates Frame based on X, Y, Width, Height
  • Handles Adornment thickness
  • Calculates Viewport
  • Lays out SubViews recursively

Drawing

See the Drawing Deep Dive for complete details.

Views draw themselves using viewport-relative coordinates:

protected override bool OnDrawingContent()
{
    // Draw at viewport coordinates (0,0)
    Move(0, 0);
    SetAttribute(new Attribute(Color.White, Color.Blue));
    AddStr("Hello, Terminal.Gui!");
    
    return true;
}

Key drawing concepts:

Navigation

See the Navigation Deep Dive for complete details.

Navigation controls keyboard focus movement:

Scrolling

See the Scrolling Deep Dive for complete details.

Scrolling is built into every View:

// Set content size larger than viewport
view.SetContentSize(new Size(100, 100));

// Scroll the content
view.Viewport = view.Viewport with { Location = new Point(10, 10) };

// Or use helper methods
view.ScrollVertical(5);
view.ScrollHorizontal(3);

// Enable scrollbars
view.VerticalScrollBar.Visible = true;
view.HorizontalScrollBar.Visible = true;

Common View Patterns

Creating a Custom View

public class MyCustomView : View
{
    public MyCustomView()
    {
        // Set up default size
        Width = Dim.Auto();
        Height = Dim.Auto();
        
        // Can receive focus
        CanFocus = true;
        
        // Add supported commands
        AddCommand(Command.Accept, HandleAccept);
        
        // Configure key bindings
        KeyBindings.Add(Key.Enter, Command.Accept);
    }
    
    protected override bool OnDrawingContent()
    {
        // Draw custom content using viewport coordinates
        Move(0, 0);
        SetAttributeForRole(VisualRole.Normal);
        AddStr("My custom content");
        
        return true; // Handled
    }
    
    private bool HandleAccept()
    {
        // Handle the Accept command
        // Raise events, update state, etc.
        return true; // Handled
    }
}

Adding SubViews

var container = new View
{
    Width = Dim.Fill(),
    Height = Dim.Fill()
};

var button1 = new Button { Text = "OK", X = 2, Y = 2 };
var button2 = new Button { Text = "Cancel", X = Pos.Right(button1) + 2, Y = 2 };

container.Add(button1, button2);

Using Adornments

var view = new View
{
    BorderStyle = LineStyle.Double,
    Title = "My View"
};

// Configure border
view.Border.Thickness = new Thickness(1);
view.Border.Settings = BorderSettings.Title;

// Add padding
view.Padding.Thickness = new Thickness(1);

// Add margin
view.Margin.Thickness = new Thickness(2);

Implementing Scrolling

var view = new View
{
    Width = 40,
    Height = 20
};

// Set content larger than viewport
view.SetContentSize(new Size(100, 100));

// Enable scrollbars with auto-show
view.VerticalScrollBar.AutoShow = true;
view.HorizontalScrollBar.AutoShow = true;

// Add key bindings for scrolling
view.KeyBindings.Add(Key.CursorUp, Command.ScrollUp);
view.KeyBindings.Add(Key.CursorDown, Command.ScrollDown);
view.KeyBindings.Add(Key.CursorLeft, Command.ScrollLeft);
view.KeyBindings.Add(Key.CursorRight, Command.ScrollRight);

// Add command handlers
view.AddCommand(Command.ScrollUp, () => { view.ScrollVertical(-1); return true; });
view.AddCommand(Command.ScrollDown, () => { view.ScrollVertical(1); return true; });

Modal Views

Views can run modally (exclusively capturing all input until closed). See Toplevel for details.

Running a View Modally

var dialog = new Dialog
{
    Title = "Confirmation",
    Width = Dim.Percent(50),
    Height = Dim.Percent(50)
};

// Add content...
var label = new Label { Text = "Are you sure?", X = Pos.Center(), Y = 1 };
dialog.Add(label);

// Run modally - blocks until closed
Application.Run(dialog);

// Dialog has been closed

Modal View Types

  • Toplevel - Base class for modal views, can fill entire screen
  • Window - Overlapped container with border and title
  • Dialog - Modal Window, centered with button support
  • Wizard - Multi-step modal dialog

Dialog Example

Dialogs are Modal Windows centered on screen:

bool okPressed = false;
var ok = new Button { Text = "Ok" };
ok.Accepting += (s, e) => { okPressed = true; Application.RequestStop(); };

var cancel = new Button { Text = "Cancel" };
cancel.Accepting += (s, e) => Application.RequestStop();

var dialog = new Dialog 
{ 
    Title = "Quit",
    Width = 50,
    Height = 10
};
dialog.Add(new Label { Text = "Are you sure you want to quit?", X = Pos.Center(), Y = 2 });
dialog.AddButton(ok);
dialog.AddButton(cancel);

Application.Run(dialog);

if (okPressed)
{
    // User clicked OK
}

Which displays:

╔═ Quit ═══════════════════════════════════════════╗
║                                                  ║
║          Are you sure you want to quit?         ║
║                                                  ║
║                                                  ║
║                                                  ║
║                [ Ok ]  [ Cancel ]                ║
╚══════════════════════════════════════════════════╝

Wizard Example

Wizards let users step through multiple pages:

var wizard = new Wizard { Title = "Setup Wizard" };

var step1 = new WizardStep { Title = "Welcome" };
step1.Add(new Label { Text = "Welcome to the wizard!", X = 1, Y = 1 });

var step2 = new WizardStep { Title = "Configuration" };
step2.Add(new TextField { X = 1, Y = 1, Width = 30 });

wizard.AddStep(step1);
wizard.AddStep(step2);

Application.Run(wizard);

Advanced Topics

View Diagnostics

View.Diagnostics - ViewDiagnosticFlags for debugging:

  • Ruler - Shows a ruler around the View
  • DrawIndicator - Shows an animated indicator when drawing
  • FramePadding - Highlights the Frame with color

View States

Shadow Effects

View.ShadowStyle - ShadowStyle for drop shadows:

view.ShadowStyle = ShadowStyle.Transparent;

See Also