mirror of
https://github.com/gui-cs/Terminal.Gui.git
synced 2025-12-26 07:47:54 +01:00
#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>
This commit is contained in:
Copilot
GitHub
@@ -32,6 +32,8 @@ See the [Views Overview](views.md) for a catalog of all built-in View subclasses
|
||||
- [View.SuperView](~/api/Terminal.Gui.ViewBase.View.yml#Terminal_Gui_ViewBase_View_SuperView) - The View's container (null if the View has no container)
|
||||
- [View.Id](~/api/Terminal.Gui.ViewBase.View.yml#Terminal_Gui_ViewBase_View_Id) - Unique identifier for the View (should be unique among siblings)
|
||||
- [View.Data](~/api/Terminal.Gui.ViewBase.View.yml#Terminal_Gui_ViewBase_View_Data) - Arbitrary data attached to the View
|
||||
- [View.App](~/api/Terminal.Gui.ViewBase.View.yml#Terminal_Gui_ViewBase_View_App) - The application context this View belongs to
|
||||
- [View.Driver](~/api/Terminal.Gui.ViewBase.View.yml#Terminal_Gui_ViewBase_View_Driver) - The driver used for rendering (derived from App). This is a shortcut to `App.Driver` for convenience.
|
||||
|
||||
---
|
||||
|
||||
@@ -103,6 +105,8 @@ Views implement [ISupportInitializeNotification](https://docs.microsoft.com/en-u
|
||||
3. **[EndInit](~/api/Terminal.Gui.ViewBase.View.yml#Terminal_Gui_ViewBase_View_EndInit)** - Signals initialization is complete; raises [View.Initialized](~/api/Terminal.Gui.ViewBase.View.yml) event
|
||||
4. **[IsInitialized](~/api/Terminal.Gui.ViewBase.View.yml#Terminal_Gui_ViewBase_View_IsInitialized)** - Property indicating if initialization is complete
|
||||
|
||||
During initialization, [View.App](~/api/Terminal.Gui.ViewBase.View.yml#Terminal_Gui_ViewBase_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](https://docs.microsoft.com/en-us/dotnet/api/system.idisposable):
|
||||
@@ -678,6 +682,7 @@ view.ShadowStyle = ShadowStyle.Transparent;
|
||||
|
||||
## See Also
|
||||
|
||||
- **[Application Deep Dive](application.md)** - Instance-based application architecture
|
||||
- **[Views Overview](views.md)** - Complete list of all built-in Views
|
||||
- **[Layout Deep Dive](layout.md)** - Detailed layout system documentation
|
||||
- **[Drawing Deep Dive](drawing.md)** - Drawing system and color management
|
||||
|
||||
552
docfx/docs/application.md
Normal file
552
docfx/docs/application.md
Normal file
@@ -0,0 +1,552 @@
|
||||
# Application Architecture
|
||||
|
||||
Terminal.Gui v2 uses an instance-based application architecture that decouples views from the global application state, improving testability and enabling multiple application contexts.
|
||||
|
||||
## View Hierarchy and Run Stack
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph ViewTree["View Hierarchy (SuperView/SubView)"]
|
||||
direction TB
|
||||
Top[Application.Current<br/>Window]
|
||||
Menu[MenuBar]
|
||||
Status[StatusBar]
|
||||
Content[Content View]
|
||||
Button1[Button]
|
||||
Button2[Button]
|
||||
|
||||
Top --> Menu
|
||||
Top --> Status
|
||||
Top --> Content
|
||||
Content --> Button1
|
||||
Content --> Button2
|
||||
end
|
||||
|
||||
subgraph Stack["Application.SessionStack"]
|
||||
direction TB
|
||||
S1[Window<br/>Currently Active]
|
||||
S2[Previous Toplevel<br/>Waiting]
|
||||
S3[Base Toplevel<br/>Waiting]
|
||||
|
||||
S1 -.-> S2 -.-> S3
|
||||
end
|
||||
|
||||
Top -.->|"same instance"| S1
|
||||
|
||||
style Top fill:#ccffcc,stroke:#339933,stroke-width:3px
|
||||
style S1 fill:#ccffcc,stroke:#339933,stroke-width:3px
|
||||
```
|
||||
|
||||
## Usage Example Flow
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant App as Application
|
||||
participant Main as Main Window
|
||||
participant Dialog as Dialog
|
||||
|
||||
Note over App: Initially empty SessionStack
|
||||
|
||||
App->>Main: Run(mainWindow)
|
||||
activate Main
|
||||
Note over App: SessionStack: [Main]<br/>Current: Main
|
||||
|
||||
Main->>Dialog: Run(dialog)
|
||||
activate Dialog
|
||||
Note over App: SessionStack: [Dialog, Main]<br/>Current: Dialog
|
||||
|
||||
Dialog->>App: RequestStop()
|
||||
deactivate Dialog
|
||||
Note over App: SessionStack: [Main]<br/>Current: Main
|
||||
|
||||
Main->>App: RequestStop()
|
||||
deactivate Main
|
||||
Note over App: SessionStack: []<br/>Current: null
|
||||
```
|
||||
|
||||
## Key Concepts
|
||||
|
||||
### Instance-Based vs Static
|
||||
|
||||
**Terminal.Gui v2** has transitioned from a static singleton pattern to an instance-based architecture:
|
||||
|
||||
```csharp
|
||||
// OLD (v1 / early v2 - now obsolete):
|
||||
Application.Init();
|
||||
Application.Top.Add(myView);
|
||||
Application.Run();
|
||||
Application.Shutdown();
|
||||
|
||||
// NEW (v2 instance-based):
|
||||
var app = Application.Create ();
|
||||
app.Init();
|
||||
var top = new Toplevel();
|
||||
top.Add(myView);
|
||||
app.Run(top);
|
||||
app.Shutdown();
|
||||
```
|
||||
|
||||
### View.App Property
|
||||
|
||||
Every view now has an `App` property that references its application context:
|
||||
|
||||
```csharp
|
||||
public class View
|
||||
{
|
||||
/// <summary>
|
||||
/// Gets the application context for this view.
|
||||
/// </summary>
|
||||
public IApplication? App { get; internal set; }
|
||||
|
||||
/// <summary>
|
||||
/// Gets the application context, checking parent hierarchy if needed.
|
||||
/// Override to customize application resolution.
|
||||
/// </summary>
|
||||
public virtual IApplication? GetApp() => App ?? SuperView?.GetApp();
|
||||
}
|
||||
```
|
||||
|
||||
**Benefits:**
|
||||
- Views can be tested without `Application.Init()`
|
||||
- Multiple applications can coexist
|
||||
- Clear ownership: views know their context
|
||||
- Reduced global state dependencies
|
||||
|
||||
### Accessing Application from Views
|
||||
|
||||
**Recommended pattern:**
|
||||
|
||||
```csharp
|
||||
public class MyView : View
|
||||
{
|
||||
public override void OnEnter(View view)
|
||||
{
|
||||
// Use View.App instead of static Application
|
||||
App?.Current?.SetNeedsDraw();
|
||||
|
||||
// Access SessionStack
|
||||
if (App?.SessionStack.Count > 0)
|
||||
{
|
||||
// Work with sessions
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Alternative - dependency injection:**
|
||||
|
||||
```csharp
|
||||
public class MyView : View
|
||||
{
|
||||
private readonly IApplication _app;
|
||||
|
||||
public MyView(IApplication app)
|
||||
{
|
||||
_app = app;
|
||||
// Now completely decoupled from static Application
|
||||
}
|
||||
|
||||
public void DoWork()
|
||||
{
|
||||
_app.Current?.SetNeedsDraw();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## IApplication Interface
|
||||
|
||||
The `IApplication` interface defines the application contract:
|
||||
|
||||
```csharp
|
||||
public interface IApplication
|
||||
{
|
||||
/// <summary>
|
||||
/// Gets the currently running Toplevel (the "current session").
|
||||
/// Renamed from "Top" for clarity.
|
||||
/// </summary>
|
||||
Toplevel? Current { get; }
|
||||
|
||||
/// <summary>
|
||||
/// Gets the stack of running sessions.
|
||||
/// Renamed from "TopLevels" to align with SessionToken terminology.
|
||||
/// </summary>
|
||||
ConcurrentStack<Toplevel> SessionStack { get; }
|
||||
|
||||
IDriver? Driver { get; }
|
||||
IMainLoopCoordinator? MainLoop { get; }
|
||||
|
||||
void Init(string? driverName = null);
|
||||
void Shutdown();
|
||||
SessionToken? Begin(Toplevel toplevel);
|
||||
void End(SessionToken sessionToken);
|
||||
// ... other members
|
||||
}
|
||||
```
|
||||
|
||||
## Terminology Changes
|
||||
|
||||
Terminal.Gui v2 modernized its terminology for clarity:
|
||||
|
||||
### Application.Current (formerly "Top")
|
||||
|
||||
The `Current` property represents the currently running Toplevel (the active session):
|
||||
|
||||
```csharp
|
||||
// Access the current session
|
||||
Toplevel? current = app.Current;
|
||||
|
||||
// From within a view
|
||||
Toplevel? current = App?.Current;
|
||||
```
|
||||
|
||||
**Why "Current" instead of "Top"?**
|
||||
- Follows .NET patterns (`Thread.CurrentThread`, `HttpContext.Current`)
|
||||
- Self-documenting: immediately clear it's the "current" active view
|
||||
- Less confusing than "Top" which could mean "topmost in Z-order"
|
||||
|
||||
### Application.SessionStack (formerly "TopLevels")
|
||||
|
||||
The `SessionStack` property is the stack of running sessions:
|
||||
|
||||
```csharp
|
||||
// Access all running sessions
|
||||
foreach (var toplevel in app.SessionStack)
|
||||
{
|
||||
// Process each session
|
||||
}
|
||||
|
||||
// From within a view
|
||||
int sessionCount = App?.SessionStack.Count ?? 0;
|
||||
```
|
||||
|
||||
**Why "SessionStack" instead of "TopLevels"?**
|
||||
- Describes both content (sessions) and structure (stack)
|
||||
- Aligns with `SessionToken` terminology
|
||||
- Follows .NET naming patterns (descriptive + collection type)
|
||||
|
||||
## Migration from Static Application
|
||||
|
||||
The static `Application` class now delegates to `ApplicationImpl.Instance` and is marked obsolete:
|
||||
|
||||
```csharp
|
||||
public static class Application
|
||||
{
|
||||
[Obsolete("Use ApplicationImpl.Instance.Current or view.App?.Current")]
|
||||
public static Toplevel? Current => Instance?.Current;
|
||||
|
||||
[Obsolete("Use ApplicationImpl.Instance.SessionStack or view.App?.SessionStack")]
|
||||
public static ConcurrentStack<Toplevel> SessionStack => Instance?.SessionStack ?? new();
|
||||
}
|
||||
```
|
||||
|
||||
### Migration Strategies
|
||||
|
||||
**Strategy 1: Use View.App**
|
||||
|
||||
```csharp
|
||||
// OLD:
|
||||
void MyMethod()
|
||||
{
|
||||
Application.Current?.SetNeedsDraw();
|
||||
}
|
||||
|
||||
// NEW:
|
||||
void MyMethod(View view)
|
||||
{
|
||||
view.App?.Current?.SetNeedsDraw();
|
||||
}
|
||||
```
|
||||
|
||||
**Strategy 2: Pass IApplication**
|
||||
|
||||
```csharp
|
||||
// OLD:
|
||||
void ProcessSessions()
|
||||
{
|
||||
foreach (var toplevel in Application.SessionStack)
|
||||
{
|
||||
// Process
|
||||
}
|
||||
}
|
||||
|
||||
// NEW:
|
||||
void ProcessSessions(IApplication app)
|
||||
{
|
||||
foreach (var toplevel in app.SessionStack)
|
||||
{
|
||||
// Process
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Strategy 3: Store IApplication Reference**
|
||||
|
||||
```csharp
|
||||
public class MyService
|
||||
{
|
||||
private readonly IApplication _app;
|
||||
|
||||
public MyService(IApplication app)
|
||||
{
|
||||
_app = app;
|
||||
}
|
||||
|
||||
public void DoWork()
|
||||
{
|
||||
_app.Current?.Title = "Processing...";
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Session Management
|
||||
|
||||
### Begin and End
|
||||
|
||||
Applications manage sessions through `Begin()` and `End()`:
|
||||
|
||||
```csharp
|
||||
var app = Application.Create ();
|
||||
app.Init();
|
||||
|
||||
var toplevel = new Toplevel();
|
||||
|
||||
// Begin a new session - pushes to SessionStack
|
||||
SessionToken? token = app.Begin(toplevel);
|
||||
|
||||
// Current now points to this toplevel
|
||||
Debug.Assert(app.Current == toplevel);
|
||||
|
||||
// End the session - pops from SessionStack
|
||||
if (token != null)
|
||||
{
|
||||
app.End(token);
|
||||
}
|
||||
|
||||
// Current restored to previous toplevel (if any)
|
||||
```
|
||||
|
||||
### Nested Sessions
|
||||
|
||||
Multiple sessions can run nested:
|
||||
|
||||
```csharp
|
||||
var app = Application.Create ();
|
||||
app.Init();
|
||||
|
||||
// Session 1
|
||||
var main = new Toplevel { Title = "Main" };
|
||||
var token1 = app.Begin(main);
|
||||
// app.Current == main, SessionStack.Count == 1
|
||||
|
||||
// Session 2 (nested)
|
||||
var dialog = new Dialog { Title = "Dialog" };
|
||||
var token2 = app.Begin(dialog);
|
||||
// app.Current == dialog, SessionStack.Count == 2
|
||||
|
||||
// End dialog
|
||||
app.End(token2);
|
||||
// app.Current == main, SessionStack.Count == 1
|
||||
|
||||
// End main
|
||||
app.End(token1);
|
||||
// app.Current == null, SessionStack.Count == 0
|
||||
```
|
||||
|
||||
## View.Driver Property
|
||||
|
||||
Similar to `View.App`, views now have a `Driver` property:
|
||||
|
||||
```csharp
|
||||
public class View
|
||||
{
|
||||
/// <summary>
|
||||
/// Gets the driver for this view.
|
||||
/// </summary>
|
||||
public IDriver? Driver => GetDriver();
|
||||
|
||||
/// <summary>
|
||||
/// Gets the driver, checking application context if needed.
|
||||
/// Override to customize driver resolution.
|
||||
/// </summary>
|
||||
public virtual IDriver? GetDriver() => App?.Driver;
|
||||
}
|
||||
```
|
||||
|
||||
**Usage:**
|
||||
|
||||
```csharp
|
||||
public override void OnDrawContent(Rectangle viewport)
|
||||
{
|
||||
// Use view's driver instead of Application.Driver
|
||||
Driver?.Move(0, 0);
|
||||
Driver?.AddStr("Hello");
|
||||
}
|
||||
```
|
||||
|
||||
## Testing with the New Architecture
|
||||
|
||||
The instance-based architecture dramatically improves testability:
|
||||
|
||||
### Testing Views in Isolation
|
||||
|
||||
```csharp
|
||||
[Fact]
|
||||
public void MyView_DisplaysCorrectly()
|
||||
{
|
||||
// Create mock application
|
||||
var mockApp = new Mock<IApplication>();
|
||||
mockApp.Setup(a => a.Current).Returns(new Toplevel());
|
||||
|
||||
// Create view with mock app
|
||||
var view = new MyView { App = mockApp.Object };
|
||||
|
||||
// Test without Application.Init()!
|
||||
view.SetNeedsDraw();
|
||||
Assert.True(view.NeedsDraw);
|
||||
|
||||
// No Application.Shutdown() needed!
|
||||
}
|
||||
```
|
||||
|
||||
### Testing with Real ApplicationImpl
|
||||
|
||||
```csharp
|
||||
[Fact]
|
||||
public void MyView_WorksWithRealApplication()
|
||||
{
|
||||
var app = Application.Create ();
|
||||
try
|
||||
{
|
||||
app.Init(new FakeDriver());
|
||||
|
||||
var view = new MyView();
|
||||
var top = new Toplevel();
|
||||
top.Add(view);
|
||||
|
||||
app.Begin(top);
|
||||
|
||||
// View.App automatically set
|
||||
Assert.NotNull(view.App);
|
||||
Assert.Same(app, view.App);
|
||||
|
||||
// Test view behavior
|
||||
view.DoSomething();
|
||||
|
||||
}
|
||||
finally
|
||||
{
|
||||
app.Shutdown();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
### DO: Use View.App
|
||||
|
||||
```csharp
|
||||
✅ GOOD:
|
||||
public void Refresh()
|
||||
{
|
||||
App?.Current?.SetNeedsDraw();
|
||||
}
|
||||
```
|
||||
|
||||
### DON'T: Use Static Application
|
||||
|
||||
```csharp
|
||||
❌ AVOID:
|
||||
public void Refresh()
|
||||
{
|
||||
Application.Current?.SetNeedsDraw(); // Obsolete!
|
||||
}
|
||||
```
|
||||
|
||||
### DO: Pass IApplication as Dependency
|
||||
|
||||
```csharp
|
||||
✅ GOOD:
|
||||
public class Service
|
||||
{
|
||||
public Service(IApplication app) { }
|
||||
}
|
||||
```
|
||||
|
||||
### DON'T: Assume Application.Instance Exists
|
||||
|
||||
```csharp
|
||||
❌ AVOID:
|
||||
public class Service
|
||||
{
|
||||
public void DoWork()
|
||||
{
|
||||
var app = Application.Instance; // Might be null!
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### DO: Override GetApp() for Custom Resolution
|
||||
|
||||
```csharp
|
||||
✅ GOOD:
|
||||
public class SpecialView : View
|
||||
{
|
||||
private IApplication? _customApp;
|
||||
|
||||
public override IApplication? GetApp()
|
||||
{
|
||||
return _customApp ?? base.GetApp();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Advanced Scenarios
|
||||
|
||||
### Multiple Applications
|
||||
|
||||
The instance-based architecture enables multiple applications:
|
||||
|
||||
```csharp
|
||||
// Application 1
|
||||
var app1 = Application.Create ();
|
||||
app1.Init(new WindowsDriver());
|
||||
var top1 = new Toplevel { Title = "App 1" };
|
||||
// ... configure top1
|
||||
|
||||
// Application 2 (different driver!)
|
||||
var app2 = Application.Create ();
|
||||
app2.Init(new CursesDriver());
|
||||
var top2 = new Toplevel { Title = "App 2" };
|
||||
// ... configure top2
|
||||
|
||||
// Views in top1 use app1
|
||||
// Views in top2 use app2
|
||||
```
|
||||
|
||||
### Application-Agnostic Views
|
||||
|
||||
Create views that work with any application:
|
||||
|
||||
```csharp
|
||||
public class UniversalView : View
|
||||
{
|
||||
public void ShowMessage(string message)
|
||||
{
|
||||
// Works regardless of which application context
|
||||
var app = GetApp();
|
||||
if (app != null)
|
||||
{
|
||||
var msg = new MessageBox(message);
|
||||
app.Begin(msg);
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## See Also
|
||||
|
||||
- [Navigation](navigation.md) - Navigation with the instance-based architecture
|
||||
- [Keyboard](keyboard.md) - Keyboard handling through View.App
|
||||
- [Mouse](mouse.md) - Mouse handling through View.App
|
||||
- [Drivers](drivers.md) - Driver access through View.Driver
|
||||
- [Multitasking](multitasking.md) - Session management with SessionStack
|
||||
@@ -459,7 +459,7 @@ ThemeManager.ThemeChanged += (sender, e) =>
|
||||
{
|
||||
// Theme has changed
|
||||
// Refresh all views to use new theme
|
||||
Application.Top?.SetNeedsDraw();
|
||||
Application.Current?.SetNeedsDraw();
|
||||
};
|
||||
```
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ Terminal.Gui provides a set of APIs for formatting text, line drawing, and chara
|
||||
|
||||
# View Drawing API
|
||||
|
||||
Terminal.Gui apps draw using the @Terminal.Gui.ViewBase.View.Move(System.Int32,System.Int32) and @Terminal.Gui.ViewBase.View.AddRune(System.Text.Rune) APIs. Move selects the column and row of the cell and AddRune places the specified glyph in that cell using the @Terminal.Gui.Drawing.Attribute that was most recently set via @Terminal.Gui.ViewBase.View.SetAttribute(Terminal.Gui.Drawing.Attribute). The @Terminal.Gui.Drivers.ConsoleDriver caches all changed Cells and efficiently outputs them to the terminal each iteration of the Application. In other words, Terminal.Gui uses deferred rendering.
|
||||
Terminal.Gui apps draw using the @Terminal.Gui.ViewBase.View.Move(System.Int32,System.Int32) and @Terminal.Gui.ViewBase.View.AddRune(System.Text.Rune) APIs. Move selects the column and row of the cell and AddRune places the specified glyph in that cell using the @Terminal.Gui.Drawing.Attribute that was most recently set via @Terminal.Gui.ViewBase.View.SetAttribute(Terminal.Gui.Drawing.Attribute). The driver caches all changed Cells and efficiently outputs them to the terminal each iteration of the Application. In other words, Terminal.Gui uses deferred rendering.
|
||||
|
||||
## Coordinate System for Drawing
|
||||
|
||||
@@ -26,7 +26,7 @@ See [Layout](layout.md) for more details of the Terminal.Gui coordinate system.
|
||||
|
||||
1) Adding the text to a @Terminal.Gui.Text.TextFormatter object.
|
||||
2) Setting formatting options, such as @Terminal.Gui.Text.TextFormatter.Alignment.
|
||||
3) Calling @Terminal.Gui.Text.TextFormatter.Draw(System.Drawing.Rectangle,Terminal.Gui.Drawing.Attribute,Terminal.Gui.Drawing.Attribute,System.Drawing.Rectangle,Terminal.Gui.Drivers.IConsoleDriver).
|
||||
3) Calling @Terminal.Gui.Text.TextFormatter.Draw(Terminal.Gui.Drivers.IDriver, System.Drawing.Rectangle,Terminal.Gui.Drawing.Attribute,Terminal.Gui.Drawing.Attribute,System.Drawing.Rectangle).
|
||||
|
||||
## Line drawing
|
||||
|
||||
@@ -62,19 +62,17 @@ If a View need to redraw because something changed within it's Content Area it c
|
||||
|
||||
## Clipping
|
||||
|
||||
Clipping enables better performance and features like transparent margins by ensuring regions of the terminal that need to be drawn actually get drawn by the @Terminal.Gui.Drivers.ConsoleDriver. Terminal.Gui supports non-rectangular clip regions with @Terminal.Gui.Drawing.Region. @Terminal.Gui.Drivers.ConsoleDriver.Clip is the application managed clip region and is managed by @Terminal.Gui.App.Application. Developers cannot change this directly, but can use @Terminal.Gui.ViewBase.View.SetClipToScreen, @Terminal.Gui.ViewBase.View.SetClip(Terminal.Gui.Drawing.Region), @Terminal.Gui.ViewBase.View.SetClipToFrame, etc...
|
||||
Clipping enables better performance and features like transparent margins by ensuring regions of the terminal that need to be drawn actually get drawn by the driver. Terminal.Gui supports non-rectangular clip regions with @Terminal.Gui.Drawing.Region. The driver.Clip is the application managed clip region and is managed by @Terminal.Gui.App.Application. Developers cannot change this directly, but can use @Terminal.Gui.ViewBase.View.SetClipToScreen, @Terminal.Gui.ViewBase.View.SetClip(Terminal.Gui.Drawing.Region), @Terminal.Gui.ViewBase.View.SetClipToFrame, etc...
|
||||
|
||||
|
||||
## Cell
|
||||
|
||||
The @Terminal.Gui.Drawing.Cell class represents a single cell on the screen. It contains a character and an attribute. The character is of type `Rune` and the attribute is of type @Terminal.Gui.Drawing.Attribute.
|
||||
|
||||
`Cell` is not exposed directly to the developer. Instead, the @Terminal.Gui.Drivers.ConsoleDriver classes manage the `Cell` array that represents the screen.
|
||||
`Cell` is not exposed directly to the developer. Instead, the driver classes manage the `Cell` array that represents the screen.
|
||||
|
||||
To draw a `Cell` to the screen, use @Terminal.Gui.ViewBase.View.Move(System.Int32,System.Int32) to specify the row and column coordinates and then use the @Terminal.Gui.ViewBase.View.AddRune(System.Int32,System.Int32,System.Text.Rune) method to draw a single glyph.
|
||||
|
||||
// ... existing code ...
|
||||
|
||||
## Attribute
|
||||
|
||||
The @Terminal.Gui.Drawing.Attribute class represents the formatting attributes of a `Cell`. It exposes properties for the foreground and background colors as well as the text style. The foreground and background colors are of type @Terminal.Gui.Drawing.Color. Bold, underline, and other formatting attributes are supported via the @Terminal.Gui.Drawing.Attribute.Style property.
|
||||
@@ -100,8 +98,6 @@ SetAttributeForRole (VisualRole.Focus);
|
||||
AddStr ("Red on Black Underlined.");
|
||||
```
|
||||
|
||||
// ... existing code ...
|
||||
|
||||
## VisualRole
|
||||
|
||||
Represents the semantic visual role of a visual element rendered by a View (e.g., Normal text, Focused item, Active selection).
|
||||
@@ -141,4 +137,30 @@ See [View Deep Dive](View.md) for details.
|
||||
|
||||
## Diagnostics
|
||||
|
||||
The @Terminal.Gui.ViewBase.ViewDiagnosticFlags.DrawIndicator flag can be set on @Terminal.Gui.ViewBase.View.Diagnostics to cause an animated glyph to appear in the `Border` of each View. The glyph will animate each time that View's `Draw` method is called where either @Terminal.Gui.ViewBase.View.NeedsDraw or @Terminal.Gui.ViewBase.View.SubViewNeedsDraw is set.
|
||||
The @Terminal.Gui.ViewBase.ViewDiagnosticFlags.DrawIndicator flag can be set on @Terminal.Gui.ViewBase.View.Diagnostics to cause an animated glyph to appear in the `Border` of each View. The glyph will animate each time that View's `Draw` method is called where either @Terminal.Gui.ViewBase.View.NeedsDraw or @Terminal.Gui.ViewBase.View.SubViewNeedsDraw is set.
|
||||
|
||||
## Accessing Application Drawing Context
|
||||
|
||||
Views can access application-level drawing functionality through `View.App`:
|
||||
|
||||
```csharp
|
||||
public class CustomView : View
|
||||
{
|
||||
protected override bool OnDrawingContent()
|
||||
{
|
||||
// Access driver capabilities through View.App
|
||||
if (App?.Driver?.SupportsTrueColor == true)
|
||||
{
|
||||
// Use true color features
|
||||
SetAttribute(new Attribute(Color.FromRgb(255, 0, 0), Color.FromRgb(0, 0, 255)));
|
||||
}
|
||||
else
|
||||
{
|
||||
// Fallback to 16-color mode
|
||||
SetAttributeForRole(VisualRole.Normal);
|
||||
}
|
||||
|
||||
AddStr("Custom drawing with application context");
|
||||
return true;
|
||||
}
|
||||
}
|
||||
@@ -34,7 +34,7 @@ Application.Init();
|
||||
// Method 2: Pass driver name to Init
|
||||
Application.Init(driverName: "unix");
|
||||
|
||||
// Method 3: Pass a custom IConsoleDriver instance
|
||||
// Method 3: Pass a custom IDriver instance
|
||||
var customDriver = new MyCustomDriver();
|
||||
Application.Init(driver: customDriver);
|
||||
```
|
||||
@@ -56,7 +56,7 @@ The v2 driver architecture uses the **Component Factory** pattern to create plat
|
||||
|
||||
Each driver is composed of specialized components, each with a single responsibility:
|
||||
|
||||
#### IConsoleInput<T>
|
||||
#### IInput<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
|
||||
@@ -64,7 +64,7 @@ Reads raw console input events from the terminal. The generic type `T` represent
|
||||
|
||||
Runs on a dedicated input thread to avoid blocking the UI.
|
||||
|
||||
#### IConsoleOutput
|
||||
#### IOutput
|
||||
Renders the output buffer to the terminal. Handles:
|
||||
- Writing text and ANSI escape sequences
|
||||
- Setting cursor position
|
||||
@@ -88,8 +88,8 @@ Manages the screen buffer and drawing operations:
|
||||
#### 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`.
|
||||
#### DriverFacade<T>
|
||||
A unified facade that implements `IDriver` and coordinates all the components. This is what gets assigned to `Application.Driver`.
|
||||
|
||||
### Threading Model
|
||||
|
||||
@@ -105,22 +105,22 @@ The driver architecture employs a **multi-threaded design** for optimal responsi
|
||||
├──────────────────┬───────────────────┐
|
||||
│ │ │
|
||||
┌────────▼────────┐ ┌──────▼─────────┐ ┌──────▼──────────┐
|
||||
│ Input Thread │ │ Main UI Thread│ │ ConsoleDriver │
|
||||
│ Input Thread │ │ Main UI Thread│ │ Driver │
|
||||
│ │ │ │ │ Facade │
|
||||
│ IConsoleInput │ │ ApplicationMain│ │ │
|
||||
│ IInput │ │ 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>`.
|
||||
- **Input Thread**: Started by `MainLoopCoordinator`, runs `IInput.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`
|
||||
4. Renders updates via `IOutput`
|
||||
|
||||
This separation ensures that input is never lost and the UI remains responsive during intensive operations.
|
||||
|
||||
@@ -131,25 +131,25 @@ 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`
|
||||
- Starts the input thread which creates `IInput<T>`
|
||||
- Initializes the main UI loop which creates `IOutput`
|
||||
- Creates `DriverFacade<T>` and assigns to `IApplication.Driver`
|
||||
- Waits for both threads to be ready
|
||||
4. Returns control to the application
|
||||
|
||||
### Shutdown Flow
|
||||
|
||||
When `Application.Shutdown()` is called:
|
||||
When `IApplication.Shutdown()` is called:
|
||||
|
||||
1. Cancellation token is triggered
|
||||
2. Input thread exits its read loop
|
||||
3. `IConsoleOutput` is disposed
|
||||
3. `IOutput` is disposed
|
||||
4. Main thread waits for input thread to complete
|
||||
5. All resources are cleaned up
|
||||
|
||||
## Component Interfaces
|
||||
|
||||
### IConsoleDriver
|
||||
### IDriver
|
||||
|
||||
The main driver interface that the framework uses internally. Provides:
|
||||
|
||||
@@ -167,16 +167,6 @@ The main driver interface that the framework uses internally. Provides:
|
||||
- Use @Terminal.Gui.ViewBase.View.AddRune and @Terminal.Gui.ViewBase.View.AddStr for drawing
|
||||
- ViewBase infrastructure classes (in `Terminal.Gui/ViewBase/`) can access Driver when needed for framework implementation
|
||||
|
||||
### 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)
|
||||
@@ -219,79 +209,13 @@ This ensures Terminal.Gui applications can be debugged directly in Visual Studio
|
||||
- Uses `FakeConsole` for all operations
|
||||
- Allows injection of predefined input
|
||||
- Captures output for verification
|
||||
- Always used when `Application._forceFakeConsole` is true
|
||||
|
||||
## Example: Checking Driver Capabilities
|
||||
|
||||
```csharp
|
||||
Application.Init();
|
||||
|
||||
// The driver is internal - access through Application properties
|
||||
// Check screen dimensions
|
||||
var screenWidth = Application.Screen.Width;
|
||||
var screenHeight = Application.Screen.Height;
|
||||
|
||||
// Check if 24-bit color is supported
|
||||
bool supportsTrueColor = Application.Driver?.SupportsTrueColor ?? false;
|
||||
|
||||
// Access advanced components (for framework/infrastructure code only)
|
||||
if (Application.Driver is IConsoleDriverFacade facade)
|
||||
{
|
||||
// Access individual components for advanced scenarios
|
||||
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}");
|
||||
};
|
||||
}
|
||||
```
|
||||
- Always used when `IApplication.ForceDriver` is `fake`
|
||||
|
||||
**Important:** View subclasses should not access `Application.Driver`. Use the View APIs instead:
|
||||
- `View.Move(col, row)` for positioning
|
||||
- `View.AddRune()` and `View.AddStr()` for drawing
|
||||
- `Application.Screen` for screen dimensions
|
||||
- `View.App.Screen` for screen dimensions
|
||||
|
||||
## Custom Drivers
|
||||
|
||||
To create a custom driver, implement `IComponentFactory<T>`:
|
||||
|
||||
```csharp
|
||||
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:
|
||||
|
||||
```csharp
|
||||
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.).
|
||||
|
||||
**Note**: The legacy `MainLoop` infrastructure (including the `MainLoop` class, `IMainLoopDriver` interface, and `FakeMainLoop`) has been removed in favor of the modern architecture. All drivers now use the `MainLoopCoordinator` and `ApplicationMainLoop` system exclusively.
|
||||
|
||||
## See Also
|
||||
|
||||
|
||||
@@ -91,7 +91,7 @@ The Command can be invoked even if the `View` that defines them is not focused o
|
||||
|
||||
### **Key Events**
|
||||
|
||||
Keyboard events are retrieved from [Console Drivers](drivers.md) each iteration of the [Application](~/api/Terminal.Gui.App.Application.yml) [Main Loop](multitasking.md). The console driver raises the @Terminal.Gui.Drivers.ConsoleDriver.KeyDown and @Terminal.Gui.Drivers.ConsoleDriver.KeyUp events which invoke @Terminal.Gui.App.Application.RaiseKeyDownEvent* and @Terminal.Gui.App.Application.RaiseKeyUpEvent(Terminal.Gui.Input.Key) respectively.
|
||||
Keyboard events are retrieved from [Drivers](drivers.md) each iteration of the [Application](~/api/Terminal.Gui.App.Application.yml) [Main Loop](multitasking.md). The driver raises the @Terminal.Gui.Drivers.IDriver.KeyDown and @Terminal.Gui.Drivers.IDriver.KeyUp events which invoke @Terminal.Gui.App.Application.RaiseKeyDownEvent* and @Terminal.Gui.App.Application.RaiseKeyUpEvent(Terminal.Gui.Input.Key) respectively.
|
||||
|
||||
> [!NOTE]
|
||||
> Not all drivers/platforms support sensing distinct KeyUp events. These drivers will simulate KeyUp events by raising KeyUp after KeyDown.
|
||||
@@ -113,12 +113,12 @@ To define application key handling logic for an entire application in cases wher
|
||||
|
||||
## **Key Down/Up Events**
|
||||
|
||||
*Terminal.Gui* supports key up/down events with @Terminal.Gui.ViewBase.View.OnKeyDown* and @Terminal.Gui.ViewBase.View.OnKeyUp*, but not all [Console Drivers](drivers.md) do. To receive these key down and key up events, you must use a driver that supports them (e.g. `WindowsDriver`).
|
||||
*Terminal.Gui* supports key up/down events with @Terminal.Gui.ViewBase.View.OnKeyDown* and @Terminal.Gui.ViewBase.View.OnKeyUp*, but not all [Drivers](drivers.md) do. To receive these key down and key up events, you must use a driver that supports them (e.g. `WindowsDriver`).
|
||||
|
||||
# General input model
|
||||
|
||||
- Key Down and Up events are generated by `ConsoleDriver`.
|
||||
- `Application` subscribes to `ConsoleDriver.Down/Up` events and forwards them to the most-focused `TopLevel` view using `View.NewKeyDownEvent` and `View.NewKeyUpEvent`.
|
||||
- Key Down and Up events are generated by the driver.
|
||||
- `IApplication` implementations subscribe to driver KeyDown/Up events and forwards them to the most-focused `TopLevel` view using `View.NewKeyDownEvent` and `View.NewKeyUpEvent`.
|
||||
- The base (`View`) implementation of `NewKeyDownEvent` follows a pattern of "Before", "During", and "After" processing:
|
||||
- **Before**
|
||||
- If `Enabled == false` that view should *never* see keyboard (or mouse input).
|
||||
@@ -134,25 +134,19 @@ To define application key handling logic for an entire application in cases wher
|
||||
- Subclasses of `View` can (rarely) override `OnKeyDown` (or subscribe to `KeyDown`) to see keys before they are processed
|
||||
- Subclasses of `View` can (often) override `OnKeyDownNotHandled` to do key processing for keys that were not previously handled. `TextField` and `TextView` are examples.
|
||||
|
||||
## ConsoleDriver
|
||||
|
||||
* No concept of `Command` or `KeyBindings`
|
||||
* Use the low-level `KeyCode` enum.
|
||||
* Exposes non-cancelable `KeyDown/Up` events. The `OnKey/Down/Up` methods are public and can be used to simulate keyboard input (in addition to SendKeys).
|
||||
|
||||
## Application
|
||||
|
||||
* Implements support for `KeyBindingScope.Application`.
|
||||
* Keyboard functionality is now encapsulated in the @Terminal.Gui.App.IKeyboard interface, accessed via @Terminal.Gui.App.Application.Keyboard.
|
||||
* @Terminal.Gui.App.Application.Keyboard provides access to @Terminal.Gui.Input.KeyBindings, key binding configuration (QuitKey, ArrangeKey, navigation keys), and keyboard event handling.
|
||||
* For backward compatibility, @Terminal.Gui.App.Application still exposes static properties/methods that delegate to @Terminal.Gui.App.Application.Keyboard (e.g., `Application.KeyBindings`, `Application.RaiseKeyDownEvent`, `Application.QuitKey`).
|
||||
* For backward compatibility, @Terminal.Gui.App.Application still exposes static properties/methods that delegate to @Terminal.Gui.App.Application.Keyboard (e.g., `IApplication.KeyBindings`, `IApplication.RaiseKeyDownEvent`, `IApplication.QuitKey`).
|
||||
* Exposes cancelable `KeyDown/Up` events (via `Handled = true`). The `RaiseKeyDownEvent` and `RaiseKeyUpEvent` methods are public and can be used to simulate keyboard input.
|
||||
* The @Terminal.Gui.App.IKeyboard interface enables testability with isolated keyboard instances that don't depend on static Application state.
|
||||
|
||||
## View
|
||||
|
||||
* Implements support for `KeyBindings` and `HotKeyBindings`.
|
||||
* Exposes cancelable non-virtual methods for a new key event: `NewKeyDownEvent` and `NewKeyUpEvent`. These methods are called by `Application` can be called to simulate keyboard input.
|
||||
* Exposes cancelable non-virtual methods for a new key event: `NewKeyDownEvent` and `NewKeyUpEvent`. These methods are called by `IApplication` can be called to simulate keyboard input.
|
||||
* Exposes cancelable virtual methods for a new key event: `OnKeyDown` and `OnKeyUp`. These methods are called by `NewKeyDownEvent` and `NewKeyUpEvent` and can be overridden to handle keyboard input.
|
||||
|
||||
## IKeyboard Architecture
|
||||
@@ -175,9 +169,9 @@ The @Terminal.Gui.App.IKeyboard interface provides a decoupled, testable archite
|
||||
|
||||
```csharp
|
||||
// Modern approach - using IKeyboard
|
||||
Application.Keyboard.KeyBindings.Add(Key.F1, Command.HotKey);
|
||||
Application.Keyboard.RaiseKeyDownEvent(Key.Enter);
|
||||
Application.Keyboard.QuitKey = Key.Q.WithCtrl;
|
||||
App.Keyboard.KeyBindings.Add(Key.F1, Command.HotKey);
|
||||
App.Keyboard.RaiseKeyDownEvent(Key.Enter);
|
||||
App.Keyboard.QuitKey = Key.Q.WithCtrl;
|
||||
|
||||
// Legacy approach - still works (delegates to Application.Keyboard)
|
||||
Application.KeyBindings.Add(Key.F1, Command.HotKey);
|
||||
@@ -202,6 +196,24 @@ Assert.Equal(Key.Q.WithCtrl, keyboard1.QuitKey);
|
||||
Assert.Equal(Key.X.WithCtrl, keyboard2.QuitKey);
|
||||
```
|
||||
|
||||
**Accessing application context from views:**
|
||||
|
||||
```csharp
|
||||
public class MyView : View
|
||||
{
|
||||
protected override bool OnKeyDown(Key key)
|
||||
{
|
||||
// Use View.App instead of static Application
|
||||
if (key == Key.F1)
|
||||
{
|
||||
App?.Keyboard?.KeyBindings.Add(Key.F2, Command.Accept);
|
||||
return true;
|
||||
}
|
||||
return base.OnKeyDown(key);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Architecture Benefits
|
||||
|
||||
- **Parallel Testing**: Multiple test methods can create and use separate @Terminal.Gui.App.IKeyboard instances simultaneously without state interference.
|
||||
@@ -218,4 +230,10 @@ The @Terminal.Gui.App.Keyboard class implements @Terminal.Gui.App.IKeyboard and
|
||||
- **Events**: KeyDown, KeyUp events for application-level keyboard monitoring
|
||||
- **Command Implementations**: Handlers for Application-scoped commands (Quit, Suspend, Navigation, Refresh, Arrange)
|
||||
|
||||
The @Terminal.Gui.App.ApplicationImpl class creates and manages the @Terminal.Gui.App.IKeyboard instance, setting its `Application` property to `this` to provide the necessary @Terminal.Gui.App.IApplication reference.
|
||||
The @Terminal.Gui.App.ApplicationImpl class creates and manages the @Terminal.Gui.App.IKeyboard instance, setting its `IApplication` property to `this` to provide the necessary @Terminal.Gui.App.IApplication reference.
|
||||
|
||||
## Driver
|
||||
|
||||
* No concept of `Command` or `KeyBindings`
|
||||
* Use the low-level `KeyCode` enum.
|
||||
* Exposes non-cancelable `KeyDown/Up` events. The `OnKey/Down/Up` methods are public and can be used to simulate keyboard input (in addition to SendKeys)
|
||||
@@ -85,12 +85,12 @@ When measuring the screen space taken up by a `string` you can use the extension
|
||||
|
||||
In v1, @Terminal.Gui.View was derived from `Responder` which supported `IDisposable`. In v2, `Responder` has been removed and @Terminal.Gui.View is the base-class supporting `IDisposable`.
|
||||
|
||||
In v1, @Terminal.Gui./Terminal.Gui.Application.Init) automatically created a toplevel view and set [Application.Top](~/api/Terminal.Gui.Application.Top. In v2, @Terminal.Gui.App.Application.Init no longer automatically creates a toplevel or sets @Terminal.Gui.App.Application.Top; app developers must explicitly create the toplevel view and pass it to @Terminal.Gui.App.Application.Run (or use `Application.Run<myTopLevel>`). Developers are responsible for calling `Dispose` on any toplevel they create before exiting.
|
||||
In v1, @Terminal.Gui./Terminal.Gui.Application.Init) automatically created a toplevel view and set [Application.Current](~/api/Terminal.Gui.Application.Current. In v2, @Terminal.Gui.App.Application.Init no longer automatically creates a toplevel or sets @Terminal.Gui.App.Application.Current; app developers must explicitly create the toplevel view and pass it to @Terminal.Gui.App.Application.Run (or use `Application.Run<myTopLevel>`). Developers are responsible for calling `Dispose` on any toplevel they create before exiting.
|
||||
|
||||
### How to Fix
|
||||
|
||||
* Replace `Responder` with @Terminal.Gui.View
|
||||
* Update any code that assumes `Application.Init` automatically created a toplevel view and set `Application.Top`.
|
||||
* Update any code that assumes `Application.Init` automatically created a toplevel view and set `Application.Current`.
|
||||
* Update any code that assumes `Application.Init` automatically disposed of the toplevel view when the application exited.
|
||||
|
||||
## @Terminal.Gui.Pos and @Terminal.Gui.Dim types now adhere to standard C# idioms
|
||||
@@ -523,6 +523,6 @@ new (
|
||||
|
||||
* To simplify programming, any `View` added as a SubView another `View` will have it's lifecycle owned by the Superview; when a `View` is disposed, it will call `Dispose` on all the items in the `SubViews` property. Note this behavior is the same as it was in v1, just clarified.
|
||||
|
||||
* In v1, `Application.End` called `Dispose ()` on @Terminal.Gui.App.Application.Top (via `Runstate.Toplevel`). This was incorrect as it meant that after `Application.Run` returned, `Application.Top` had been disposed, and any code that wanted to interrogate the results of `Run` by accessing `Application.Top` only worked by accident. This is because GC had not actually happened; if it had the application would have crashed. In v2 `Application.End` does NOT call `Dispose`, and it is the caller to `Application.Run` who is responsible for disposing the `Toplevel` that was either passed to `Application.Run (View)` or created by `Application.Run<T> ()`.
|
||||
* In v1, `Application.End` called `Dispose ()` on @Terminal.Gui.App.Application.Current (via `Runstate.Toplevel`). This was incorrect as it meant that after `Application.Run` returned, `Application.Current` had been disposed, and any code that wanted to interrogate the results of `Run` by accessing `Application.Current` only worked by accident. This is because GC had not actually happened; if it had the application would have crashed. In v2 `Application.End` does NOT call `Dispose`, and it is the caller to `Application.Run` who is responsible for disposing the `Toplevel` that was either passed to `Application.Run (View)` or created by `Application.Run<T> ()`.
|
||||
|
||||
* Any code that creates a `Toplevel`, either by using `top = new()` or by calling either `top = Application.Run ()` or `top = ApplicationRun<T>()` must call `top.Dispose` when complete. The exception to this is if `top` is passed to `myView.Add(top)` making it a subview of `myView`. This is because the semantics of `Add` are that the `myView` takes over responsibility for the subviews lifetimes. Of course, if someone calls `myView.Remove(top)` to remove said subview, they then re-take responsbility for `top`'s lifetime and they must call `top.Dispose`.
|
||||
|
||||
@@ -66,14 +66,14 @@ Here are some common mouse binding patterns used throughout Terminal.Gui:
|
||||
|
||||
At the core of *Terminal.Gui*'s mouse API is the @Terminal.Gui.Input.MouseEventArgs class. The @Terminal.Gui.Input.MouseEventArgs class provides a platform-independent abstraction for common mouse events. Every mouse event can be fully described in a @Terminal.Gui.Input.MouseEventArgs instance, and most of the mouse-related APIs are simply helper functions for decoding a @Terminal.Gui.Input.MouseEventArgs.
|
||||
|
||||
When the user does something with the mouse, the `ConsoleDriver` maps the platform-specific mouse event into a `MouseEventArgs` and calls `Application.RaiseMouseEvent`. Then, `Application.RaiseMouseEvent` determines which `View` the event should go to. The `View.OnMouseEvent` method can be overridden or the `View.MouseEvent` event can be subscribed to, to handle the low-level mouse event. If the low-level event is not handled by a view, `Application` will then call the appropriate high-level helper APIs. For example, if the user double-clicks the mouse, `View.OnMouseClick` will be called/`View.MouseClick` will be raised with the event arguments indicating which mouse button was double-clicked.
|
||||
When the user does something with the mouse, the driver maps the platform-specific mouse event into a `MouseEventArgs` and calls `IApplication.Mouse.RaiseMouseEvent`. Then, `IApplication.Mouse.RaiseMouseEvent` determines which `View` the event should go to. The `View.OnMouseEvent` method can be overridden or the `View.MouseEvent` event can be subscribed to, to handle the low-level mouse event. If the low-level event is not handled by a view, `IApplication` will then call the appropriate high-level helper APIs. For example, if the user double-clicks the mouse, `View.OnMouseClick` will be called/`View.MouseClick` will be raised with the event arguments indicating which mouse button was double-clicked.
|
||||
|
||||
### Mouse Event Processing Flow
|
||||
|
||||
Mouse events are processed through the following workflow using the [Cancellable Work Pattern](cancellable-work-pattern.md):
|
||||
|
||||
1. **Driver Level**: The ConsoleDriver captures platform-specific mouse events and converts them to `MouseEventArgs`
|
||||
2. **Application Level**: `Application.RaiseMouseEvent` determines the target view and routes the event
|
||||
1. **Driver Level**: The driver captures platform-specific mouse events and converts them to `MouseEventArgs`
|
||||
2. **Application Level**: `IApplication.Mouse.RaiseMouseEvent` determines the target view and routes the event
|
||||
3. **View Level**: The target view processes the event through:
|
||||
- `OnMouseEvent` (virtual method that can be overridden)
|
||||
- `MouseEvent` event (for event subscribers)
|
||||
@@ -157,8 +157,8 @@ view.MouseStateChanged += (sender, e) =>
|
||||
|
||||
The @Terminal.Gui.App.Application.MouseEvent event can be used if an application wishes to receive all mouse events before they are processed by individual views:
|
||||
|
||||
```cs
|
||||
Application.MouseEvent += (sender, e) =>
|
||||
```csharp
|
||||
App.Mouse.MouseEvent += (sender, e) =>
|
||||
{
|
||||
// Handle application-wide mouse events
|
||||
if (e.Flags.HasFlag(MouseFlags.Button3Clicked))
|
||||
@@ -169,6 +169,24 @@ Application.MouseEvent += (sender, e) =>
|
||||
};
|
||||
```
|
||||
|
||||
For view-specific mouse handling that needs access to application context, use `View.App`:
|
||||
|
||||
```csharp
|
||||
public class MyView : View
|
||||
{
|
||||
protected override bool OnMouseEvent(MouseEventArgs mouseEvent)
|
||||
{
|
||||
if (mouseEvent.Flags.HasFlag(MouseFlags.Button3Clicked))
|
||||
{
|
||||
// Access application mouse functionality through View.App
|
||||
App?.MouseEvent?.Invoke(this, mouseEvent);
|
||||
return true;
|
||||
}
|
||||
return base.OnMouseEvent(mouseEvent);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Mouse Enter/Leave Events
|
||||
|
||||
The @Terminal.Gui.ViewBase.View.MouseEnter and @Terminal.Gui.ViewBase.View.MouseLeave events enable a View to take action when the mouse enters or exits the view boundary. Internally, this is used to enable @Terminal.Gui.ViewBase.View.Highlight functionality:
|
||||
@@ -218,3 +236,4 @@ The `MouseEventArgs` provides both coordinate systems:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -374,7 +374,7 @@ In v1 `View` had `MostFocused` property that traversed up the view-hierarchy ret
|
||||
var focused = Application.Navigation.GetFocused();
|
||||
|
||||
// This replaces the v1 pattern:
|
||||
// var focused = Application.Top.MostFocused;
|
||||
// var focused = Application.Current.MostFocused;
|
||||
```
|
||||
|
||||
## How Does `View.Add/Remove` Work?
|
||||
|
||||
@@ -26,6 +26,8 @@
|
||||
href: events.md
|
||||
- name: Lexicon & Taxonomy
|
||||
href: lexicon.md
|
||||
- name: Terminology Proposal
|
||||
href: terminology-index.md
|
||||
- name: Keyboard
|
||||
href: keyboard.md
|
||||
- name: Layout Engine
|
||||
|
||||
@@ -220,7 +220,7 @@
|
||||
"additionalProperties": true,
|
||||
"definitions": {
|
||||
"Color": {
|
||||
"description": "One be either one of the W3C standard color names (parsed case-insensitively), a ColorName16 (e.g. 'BrightBlue', parsed case-insensitively), an rgb(r,g,b) tuple, or a hex color string in the format #RRGGBB.",
|
||||
"description": "One of the standard color names (parsed case-insensitively; (e.g. 'BrightBlue'), an rgb(r,g,b) tuple, or a hex color string in the format #RRGGBB.",
|
||||
"$schema": "http://json-schema.org/draft-07/schema#",
|
||||
"type": "string",
|
||||
"oneOf": [
|
||||
|
||||
Reference in New Issue
Block a user