Files
Terminal.Gui/docfx/docs/drivers.md
Copilot 2be8397203 Remove legacy drivers, simplify architecture, and reorganize codebase structure (#4270)
* Initial plan

* Remove legacy drivers and reorganize v2 architecture

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

* Extract Windows key helper utilities and fix build

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

* Fix all test references to legacy drivers

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

* Update documentation to reflect new driver architecture

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

* Remove V2.cd diagram file

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

* Fix test failures: support legacy drivers and update exception handling

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

* updated driver names

* Move V2 tests from ConsoleDrivers/V2 to proper locations

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

* Rename ApplicationV2 to ModernApplicationImpl to remove v2 terminology

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

* Remove V2 terminology from test drivers and FakeDriver classes

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

* Merge ModernApplicationImpl into ApplicationImpl and move to App folder

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

* Create modern FakeDriver with component factory architecture in Terminal.Gui project

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

* Refactor: Move non-platform-dependent code from /Drivers to /App

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

* Code cleanup and org

* Unit test reorg

* Refactor MainLoop architecture: rename classes and enhance documentation for clarity

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

* Add comprehensive FakeDriver tests (WIP - some tests need fixes)

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

* Fixed FakeDriver build failures

* Fix all FakeDriver test failures - Application.Top creation and clipboard behaviors

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

* Fixed FakeDriver build failures2

* Remove hanging legacy FakeDriver tests that use Console.MockKeyPresses

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

* Fixed some tests

* Fixed more tests

* Fixed more tests

* Fix bad copilot (#4277)

* Update Terminal.Gui/Drivers/FakeDriver/FakeConsoleOutput.cs

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Refactor Application Init and Update Tests

Refactored `Application.Init` to improve initialization logic:
- Added fallback to `ForceDriver` when `driverName` is null.
- Changed repeated `Init` calls to throw `InvalidOperationException`.
- Updated `_driverName` assignment logic for robustness.

Enhanced `IConsoleDriver` with detailed remarks on implementations.

Revised test cases to align with updated `Application.Init` behavior:
- Replaced `FakeDriver` with `null` and `driverName: "fake"`.
- Skipped or commented out tests incompatible with new logic.
- Improved formatting and removed redundant setup code.

Improved code style and consistency across the codebase:
- Standardized parameter formatting and spacing.
- Removed outdated comments and unused code.

General cleanup to enhance readability and maintainability.

* Warp fix copilot (#4278)

* More fixes (#4279)

* Fixes/works around test failures and temporarily disable failing test

Updated `FakeDriver` to set `RunningUnitTests` to `true` and initialize dimensions using `FakeConsole`. Modified `TestRespondersDisposedAttribute` to set `ConsoleDriver.RunningUnitTests` in the `Before` method, ensuring proper behavior during unit tests.

Temporarily disabled the `Button_CanFocus_False_Raises_Accepted_Correctly` test in `ViewCommandTests` by adding a `Skip` parameter to the `[Fact]` attribute, referencing issue #4270.

* Allow all tests to run despite failures in UnitTests

Modified the `dotnet test` command in the `Run UnitTestsParallelizable` step to set `xunit.stopOnFail` to `false`. This ensures that the test runner does not stop execution on the first failure, allowing all tests to execute regardless of individual test outcomes.

* Refactor ApplicationScreenTests for cleaner setup/teardown

Refactored `ClearContents_Called_When_Top_Frame_Changes` test:
- Added `[AutoInitShutdown]` attribute for automatic lifecycle management.
- Replaced manual `Application.Init` and `Application.Top` setup with `Application.Begin` and `RunState`.
- Simplified event handling by defining `ClearedContents` handler inline.
- Removed explicit cleanup logic, relying on `Application.End` for teardown.

Updated `using` directives to include `UnitTests` namespace.

* Attempt to fix intermittent local test failures.

Update ApplicationImpl initialization parameter

Changed the second parameter of the `impl.Init` method in the
`FakeApplicationFactory` class from `"dotnet"` to `"fake"`.

* Code cleanup to cause Action to re-run.

* Stop tests on first failure in UnitTestsParallelizable

Updated the `dotnet test` command in `unit-tests.yml` to set the `xunit.stopOnFail` parameter to `true`. This change ensures that test execution halts immediately upon encountering a failure, allowing quicker identification and resolution of issues. Note that this may prevent the full test suite from running in the event of a failure.

* Allow all tests to run despite failures in CI

Updated `unit-tests.yml` to set `xunit.stopOnFail` to `false`
in both `Run UnitTests` and `Run UnitTestsParallelizable`
steps. This ensures that the test runner does not stop
execution on the first test failure, allowing all tests
to complete even if some fail.

* Enhance RuneExtensions docs and update user dictionary

Updated the `<remarks>` section in `RuneExtensions.GetColumns` to include details about the `wcwidth` implementation and improved readability with `<para>` tags. Added `wcwidth` to the user dictionary in `Terminal.sln.DotSettings` to avoid spelling errors.

* Improve XML doc formatting in RuneExtensions.cs

Updated the remarks section of the `GetColumns` method in the
`RuneExtensions` class to enhance readability by reformatting
and properly indenting `<para>` tags. The content remains
unchanged, describing the method's implementation via `wcwidth`
and its role as a Terminal.Gui extension for `System.Text.Rune`.

* Refactor drivers and improve clipboard handling

Replaced legacy drivers (`CursesDriver`, `NetDriver`) with
`UnixDriver` and `DotNetDriver` across the codebase, including
comments, method names, and test cases. Updated documentation
and remarks to reflect the new driver names and platforms.

Revamped clipboard handling with new platform-specific
implementations: `UnixClipboard` for Unix, `MacOSXClipboard`
for macOS, and `WSLClipboard` for Linux under WSL. Removed
the old `CursesClipboard` and consolidated clipboard logic.

Updated test cases to align with the new drivers and clipboard
implementations. Improved naming consistency and cleaned up
redundant code. Updated the README and documentation to
reflect these changes.

* Remove `PlatformColor` from `Attribute` struct

This commit removes the `PlatformColor` property from the `Attribute` struct, simplifying the codebase by eliminating platform-specific color handling. The following changes were made:

- Removed `PlatformColor` from the `Attribute` struct, including its initialization, usage, and related comments.
- Updated constructors to no longer initialize or use `PlatformColor`.
- Modified `Equals` and `GetHashCode` methods to exclude `PlatformColor`.
- Updated `UnixComponentFactory` documentation to remove references to "v2unix."
- Renamed `v2TestDriver` to `testDriver` in the `With` class for clarity.
- Removed `PlatformColor` references in `DriverAssert` and related error messages.
- Deleted test cases in `AttributeTests` that relied on `PlatformColor`.
- Cleaned up comments and TODOs related to `PlatformColor` and `UnixDriver`.

These changes reflect a shift away from platform-dependent color management, improving code clarity and reducing complexity.

Remove `PlatformColor` and simplify `Attribute` logic

The `PlatformColor` property has been removed from the `Attribute` struct, along with its associated logic, simplifying the codebase and eliminating platform-specific dependencies. Constructors, equality checks, and hash code generation in `Attribute` have been updated accordingly.

The `CurrentAttribute` property in `ConsoleDriver` and `OutputBuffer` has been simplified, removing dependencies on `Application.Driver`. The `MakeColor` method logic has been removed or simplified in related classes.

Tests in `AttributeTests` have been refactored to reflect these changes, focusing on `Foreground`, `Background`, and `Style`. Unix-specific logic tied to `PlatformColor` has been eliminated.

Additional updates include renaming parameters in the `With` class for clarity, simplifying `DriverAssert` output, and performing minor code cleanups to improve readability and maintainability.

* Refactor Terminal.Gui driver architecture for v2

Updated documentation to reflect the new modular driver architecture in Terminal.Gui v2.

- Revised `namespace-drivers.md` to include new components (`IConsoleInput`, `IConsoleOutput`, `IInputProcessor`, `IOutputBuffer`, `IWindowSizeMonitor`) and terminal size monitoring.
- Replaced "Key Components" with "Architecture Overview" and added details on the **Component Factory** pattern.
- Documented the four driver implementations (`DotNetDriver`, `WindowsDriver`, `UnixDriver`, `FakeDriver`) and their platform-specific optimizations.
- Added a "Threading Model" section to explain the multi-threaded design for responsive input handling.
- Updated examples to demonstrate driver capabilities and explicit driver selection.

In `drivers.md`:
- Expanded the "Overview" to emphasize the modular, component-based architecture.
- Reorganized "Drivers" into "Available Drivers" and added details on `FakeDriver` for unit testing.
- Added sections on "Initialization Flow," "Shutdown Flow," and platform-specific driver details.
- Provided examples for accessing driver components and creating custom drivers.

In `index.md`:
- Updated "Cross Platform" feature to reflect new driver names and clarified compatibility with SSH and monochrome terminals.

* Moved files around

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: tig <585482+tig@users.noreply.github.com>
Co-authored-by: Tig <tig@users.noreply.github.com>
Co-authored-by: Thomas Nind <31306100+tznind@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
2025-10-15 13:24:47 -06:00

10 KiB

Cross-Platform Driver Model

Overview

The driver model is the mechanism by which Terminal.Gui supports multiple platforms. Windows, Mac, Linux, and unit test environments are all supported through a modular, component-based architecture.

Terminal.Gui v2 uses a sophisticated driver architecture that separates concerns and enables platform-specific optimizations while maintaining a consistent API. The architecture is based on the Component Factory pattern and uses multi-threading to ensure responsive input handling.

Available Drivers

Terminal.Gui provides console driver implementations optimized for different platforms:

  • DotNetDriver (dotnet) - A cross-platform driver that uses the .NET System.Console API. Works on all platforms (Windows, macOS, Linux). Best for maximum compatibility.
  • WindowsDriver (windows) - A Windows-optimized driver that uses native Windows Console APIs for enhanced performance and platform-specific features.
  • UnixDriver (unix) - A Unix/Linux/macOS-optimized driver that uses platform-specific APIs for better integration and performance.
  • FakeDriver (fake) - A mock driver designed for unit testing. Simulates console behavior without requiring a real terminal.

Automatic Driver Selection

The appropriate driver is automatically selected based on the platform when you call Application.Init():

  • Windows (Win32NT, Win32S, Win32Windows) → WindowsDriver
  • Unix/Linux/macOSUnixDriver

Explicit Driver Selection

You can explicitly specify a driver in three ways:

// Method 1: Set ForceDriver property before Init
Application.ForceDriver = "dotnet";
Application.Init();

// Method 2: Pass driver name to Init
Application.Init(driverName: "unix");

// Method 3: Pass a custom IConsoleDriver instance
var customDriver = new MyCustomDriver();
Application.Init(driver: customDriver);

Valid driver names: "dotnet", "windows", "unix", "fake"

Architecture

Component Factory Pattern

The v2 driver architecture uses the Component Factory pattern to create platform-specific components. Each driver has a corresponding factory:

  • NetComponentFactory - Creates components for DotNetDriver
  • WindowsComponentFactory - Creates components for WindowsDriver
  • UnixComponentFactory - Creates components for UnixDriver
  • FakeComponentFactory - Creates components for FakeDriver

Core Components

Each driver is composed of specialized components, each with a single responsibility:

IConsoleInput<T>

Reads raw console input events from the terminal. The generic type T represents the platform-specific input type:

  • ConsoleKeyInfo for DotNetDriver and FakeDriver
  • WindowsConsole.InputRecord for WindowsDriver
  • char for UnixDriver

Runs on a dedicated input thread to avoid blocking the UI.

IConsoleOutput

Renders the output buffer to the terminal. Handles:

  • Writing text and ANSI escape sequences
  • Setting cursor position
  • Managing cursor visibility
  • Detecting terminal window size

IInputProcessor

Translates raw console input into Terminal.Gui events:

  • Converts raw input to Key events (handles keyboard input)
  • Parses ANSI escape sequences (mouse events, special keys)
  • Generates MouseEventArgs for mouse input
  • Handles platform-specific key mappings

IOutputBuffer

Manages the screen buffer and drawing operations:

  • Maintains the Contents array (what should be displayed)
  • Provides methods like AddRune(), AddStr(), Move(), FillRect()
  • Handles clipping regions
  • Tracks dirty regions for efficient rendering

IWindowSizeMonitor

Detects terminal size changes and raises SizeChanged events when the terminal is resized.

ConsoleDriverFacade<T>

A unified facade that implements IConsoleDriver and coordinates all the components. This is what gets assigned to Application.Driver.

Threading Model

The driver architecture employs a multi-threaded design for optimal responsiveness:

┌─────────────────────────────────────────────┐
│         ApplicationImpl.Init()              │
│  Creates MainLoopCoordinator<T> with        │
│  ComponentFactory<T>                        │
└────────────────┬────────────────────────────┘
                 │
                 ├──────────────────┬───────────────────┐
                 │                  │                   │
        ┌────────▼────────┐ ┌──────▼─────────┐ ┌──────▼──────────┐
        │  Input Thread   │ │  Main UI Thread│ │ ConsoleDriver   │
        │                 │ │                 │ │   Facade        │
        │ IConsoleInput   │ │ ApplicationMain│ │                 │
        │ reads console   │ │ Loop processes │ │ Coordinates all │
        │ input async     │ │ events, layout,│ │ components      │
        │ into queue      │ │ and rendering  │ │                 │
        └─────────────────┘ └────────────────┘ └─────────────────┘
  • Input Thread: Started by MainLoopCoordinator, runs IConsoleInput.Run() which continuously reads console input and queues it into a thread-safe ConcurrentQueue<T>.

  • Main UI Thread: Runs ApplicationMainLoop.Iteration() which:

    1. Processes input from the queue via IInputProcessor
    2. Executes timeout callbacks
    3. Checks for UI changes (layout/drawing)
    4. Renders updates via IConsoleOutput

This separation ensures that input is never lost and the UI remains responsive during intensive operations.

Initialization Flow

When you call Application.Init():

  1. ApplicationImpl.Init() is invoked
  2. Creates a MainLoopCoordinator<T> with the appropriate ComponentFactory<T>
  3. MainLoopCoordinator.StartAsync() begins:
    • Starts the input thread which creates IConsoleInput<T>
    • Initializes the main UI loop which creates IConsoleOutput
    • Creates ConsoleDriverFacade<T> and assigns to Application.Driver
    • Waits for both threads to be ready
  4. Returns control to the application

Shutdown Flow

When Application.Shutdown() is called:

  1. Cancellation token is triggered
  2. Input thread exits its read loop
  3. IConsoleOutput is disposed
  4. Main thread waits for input thread to complete
  5. All resources are cleaned up

Component Interfaces

IConsoleDriver

The main driver interface that applications interact with. Provides:

  • Screen Management: Screen, Cols, Rows, Contents
  • Drawing Operations: AddRune(), AddStr(), Move(), FillRect()
  • Cursor Management: SetCursorVisibility(), UpdateCursor()
  • Attribute Management: CurrentAttribute, SetAttribute(), MakeColor()
  • Clipping: Clip property
  • Events: KeyDown, KeyUp, MouseEvent, SizeChanged
  • Platform Features: SupportsTrueColor, Force16Colors, Clipboard

IConsoleDriverFacade

Extended interface for v2 drivers that exposes the internal components:

  • IInputProcessor InputProcessor
  • IOutputBuffer OutputBuffer
  • IWindowSizeMonitor WindowSizeMonitor

This interface allows advanced scenarios and testing.

Platform-Specific Details

DotNetDriver (NetComponentFactory)

  • Uses System.Console for all I/O operations
  • Input: Reads ConsoleKeyInfo via Console.ReadKey()
  • Output: Uses Console.Write() and ANSI escape sequences
  • Works on all platforms but may have limited features
  • Best for maximum compatibility and simple applications

WindowsDriver (WindowsComponentFactory)

  • Uses Windows Console API via P/Invoke
  • Input: Reads InputRecord structs via ReadConsoleInput
  • Output: Uses Windows Console API for optimal performance
  • Supports Windows-specific features and better performance
  • Automatically selected on Windows platforms

UnixDriver (UnixComponentFactory)

  • Uses Unix/Linux terminal APIs
  • Input: Reads raw char data from terminal
  • Output: Uses ANSI escape sequences
  • Supports Unix-specific features
  • Automatically selected on Unix/Linux/macOS platforms

FakeDriver (FakeComponentFactory)

  • Simulates console behavior for unit testing
  • Uses FakeConsole for all operations
  • Allows injection of predefined input
  • Captures output for verification
  • Always used when Application._forceFakeConsole is true

Example: Accessing Driver Components

Application.Init();

// Access the driver
IConsoleDriver driver = Application.Driver;

// Check if it's a v2 driver with facade
if (driver is IConsoleDriverFacade facade)
{
    // Access individual components
    IInputProcessor inputProcessor = facade.InputProcessor;
    IOutputBuffer outputBuffer = facade.OutputBuffer;
    IWindowSizeMonitor sizeMonitor = facade.WindowSizeMonitor;
    
    // Use components for advanced scenarios
    sizeMonitor.SizeChanging += (s, e) => 
    {
        Console.WriteLine($"Terminal resized to {e.Size}");
    };
}

Custom Drivers

To create a custom driver, implement IComponentFactory<T>:

public class MyComponentFactory : ComponentFactory<MyInputType>
{
    public override IConsoleInput<MyInputType> CreateInput()
    {
        return new MyConsoleInput();
    }
    
    public override IConsoleOutput CreateOutput()
    {
        return new MyConsoleOutput();
    }
    
    public override IInputProcessor CreateInputProcessor(
        ConcurrentQueue<MyInputType> inputBuffer)
    {
        return new MyInputProcessor(inputBuffer);
    }
}

Then use it:

ApplicationImpl.ChangeComponentFactory(new MyComponentFactory());
Application.Init();

Legacy Drivers

Terminal.Gui v1 drivers that implement IConsoleDriver but not IConsoleDriverFacade are still supported through a legacy compatibility layer. However, they do not benefit from the v2 architecture improvements (multi-threading, component separation, etc.).

See Also

  • @Terminal.Gui.Drivers - API Reference
  • @Terminal.Gui.App.Application - Application class
  • @Terminal.Gui.App.ApplicationImpl - Application implementation
  • @Terminal.Gui.App.MainLoopCoordinator`1 - Main loop coordination