Files
Terminal.Gui/Examples/UICatalog
Copilot e199063a31 Introduce IRunnable interface architecture with Fluent API (Phase 1) (#4405)
* Initial plan

* Add IRunnable interface, Runnable base class, and RunnableSessionToken

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

* Add comprehensive parallelizable unit tests for IRunnable

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

* Add 41 more unit tests for comprehensive IRunnable coverage

- Added ApplicationRunnableIntegrationTests with 29 integration tests covering Begin/End/Run lifecycle
- Added RunnableEdgeCasesTests with 24 edge case and error condition tests
- Tests cover event propagation, cancellation scenarios, nested runnables, result handling
- Fixed App property not being set in Begin() method
- Total test count increased from 23 to 64 tests for IRunnable functionality

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

* Fix parallel test failures in CI/CD

- Fixed IsModal property to check RunnableSessionStack instead of just TopRunnable
- Added "fake" driver parameter to Application.Init() in integration tests
- Fixed Begin() to capture old IsModal value before pushing to stack
- Moved App property assignment before stack operations to ensure proper state
- Skipped 2 tests that use Run() with main loop (not suitable for parallel tests)
- All 11,654 parallelizable tests now pass (4 skipped)

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

* Refactor Application with IRunnable and session management

Modernized `Application` and `ApplicationImpl` by introducing `IRunnable` and `RunnableSessionToken` for improved session management. Deprecated legacy methods and added `Obsolete` attributes to indicate their removal. Simplified method bodies using expression-bodied members and null-coalescing assignments.

Enhanced lifecycle management in `ApplicationImpl` by removing redundant code and improving `SessionStack` iteration. Introduced `IToplevelTransitionManager` to handle top-level state changes.

Updated `Runnable<TResult>` to implement `IRunnable<TResult>` with lifecycle event handling for `IsRunning` and `IsModal` states. Improved result management during lifecycle transitions.

Removed legacy classes like `SessionToken` and consolidated their functionality into the new constructs. Updated and expanded the test suite to cover `IRunnable` lifecycle events, `RunnableSessionToken` behavior, and integration with `Application`.

Performed code cleanup, improved readability, and updated documentation with detailed remarks and examples. Added new unit tests for edge cases and lifecycle behavior.

* Implement fluent API for Init/Run/Shutdown with automatic disposal

- Changed Init() to return IApplication for fluent chaining
- Changed Run<TRunnable>() to return IApplication (breaking change from TRunnable)
- Changed Shutdown() to return object? (extracts and returns result from last Run<T>())
- Added FrameworkOwnedRunnable property to track runnable created by Run<T>()
- Shutdown() automatically disposes framework-owned runnables
- Created FluentExample demonstrating: Application.Create().Init().Run<ColorPickerView>().Shutdown()
- Disposal semantics: framework creates → framework disposes; caller creates → caller disposes

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

* New Example: Demonstrates new Fluent API using ColorPicker

Conditional compilation (`#if POST_4148`) to support both a new Fluent API and a traditional approach for running `ColorPickerView`. The Fluent API simplifies the application lifecycle with method chaining and automatic disposal, while the traditional approach retains explicit lifecycle management.

Refactor `ColorPickerView` to support both approaches:
- Add an `instructions` label for user guidance.
- Replace `_okButton` and `_cancelButton` with local `Button` instances.
- Use a new `ColorPicker` with enhanced styling options.

Add a warning log for WIP issue (#4148) in `ApplicationImpl.Run.cs` to highlight limitations with non-`Toplevel` views as runnables.

Update `Terminal.sln` to include the new `FluentExample` project with appropriate build configurations.

Improve code readability with verbatim string literals and better alignment/indentation.

* Introduce `RunnableWrapper` for making any View runnable

Added the `RunnableWrapper<TView, TResult>` pattern to enable any
`View` to be run as a blocking session with typed results, without
requiring inheritance from `Runnable<TResult>` or implementation
of `IRunnable<TResult>`.

- Added `RunnableWrapperExample` project to demonstrate usage.
- Introduced `ApplicationRunnableExtensions` and `ViewRunnableExtensions`
  for clean, type-safe APIs to run views with or without result extraction.
- Updated `CodeSharingStrategy.md` to document reduced duplication
  using `#if POST_4148` directives.
- Added `RunnableWrapper.md` with detailed documentation and examples.
- Created runnable examples in `Program.cs` showcasing various use cases.
- Improved maintainability by reducing code duplication by 86% and
  increasing shared code by 264%.
- Gated all new functionality behind the `POST_4148` feature flag
  for backward compatibility.

* Simplified `#if POST_4148` usage to reduce duplication and improve clarity. Refactored `RunnableWrapper` to use a parameterless constructor with `required` properties, ensuring type safety and better lifecycle management. Updated `AllViewsView` with new commands, improved generic handling, and enhanced logging.

Refactored `ApplicationRunnableExtensions` and `ViewRunnableExtensions` for cleaner initialization and event handling. Enhanced `TestsAllViews` to handle required properties and constraints dynamically. Updated documentation to reflect new designs and provide clearer examples.

Improved overall code readability, consistency, and maintainability while leveraging modern C# features.

* Update docfx documentation for IRunnable architecture

- Updated View.md with comprehensive IRunnable section
  - Interface-based architecture explanation
  - Fluent API patterns and examples
  - Disposal semantics ("whoever creates it, owns it")
  - Result extraction patterns
  - Lifecycle properties and CWP-compliant events
  - Marked legacy Modal Views section for clarity

- Updated application.md with IRunnable deep dive
  - Key features and benefits
  - Fluent API patterns with method chaining
  - Disposal semantics table
  - Creating runnable views with examples
  - Lifecycle properties and events
  - RunnableSessionStack management
  - Updated IApplication interface documentation

- Updated runnable-architecture-proposal.md
  - Marked Phase 1 as COMPLETE 
  - Updated status to "Phase 1 Complete - Phase 2 In Progress"
  - Documented all implemented features
  - Added bonus features (fluent API, automatic disposal)
  - Included migration examples

All documentation is now clear, concise, and complete relative to Phase 1 implementation.

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

---------

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

Terminal.Gui UI Catalog

UI Catalog is a comprehensive sample library for Terminal.Gui. It attempts to satisfy the following goals:

  1. Be an easy-to-use showcase for Terminal.Gui concepts and features.
  2. Provide sample code that illustrates how to properly implement said concepts & features.
  3. Make it easy for contributors to add additional samples in a structured way.

screenshot

Motivation

The original demo.cs sample app for Terminal.Gui is neither good to showcase, nor does it explain different concepts. In addition, because it is built on a single source file, it has proven to cause friction when multiple contributors are simultaneously working on different aspects of Terminal.Gui. See Issue #368 for more background.

API Reference

How To Use

Build and run UI Catalog by typing dotnet run from the UI Catalog folder or by using the Terminal.Gui Visual Studio solution.

Program.cs is the main UI Catalog app and provides a UI for selecting and running Scenarios. Each *Scenario is implemented as a class derived from Scenario and Program.cs uses reflection to dynamically build the UI.

Scenarios are tagged with categories using the [ScenarioCategory] attribute. The left pane of the main screen lists the categories. Clicking on a category shows all the scenarios in that category.

Scenarios can be run either from the UICatalog.exe app UI or by being specified on the command line:

UICatalog.exe <Scenario Name>

e.g.

UICatalog.exe Buttons

Hitting ENTER on a selected Scenario or double-clicking on a Scenario runs that scenario as though it were a stand-alone Terminal.Gui app.

When a Scenario is run, it runs as though it were a standalone Terminal.Gui app. However, scaffolding is provided (in the Scenario base class) that (optionally) takes care of Terminal.Gui initialization.

Contributing by Adding Scenarios

To add a new Scenario simply:

  1. Create a new .cs file in the Scenarios directory that derives from Scenario.
  2. Add a [ScenarioMetaData] attribute to the class specifying the scenario's name and description.
  3. Add one or more [ScenarioCategory] attributes to the class specifying which categories the sceanrio belongs to. If you don't specify a category the sceanrio will show up in "All".
  4. Implement the Setup override which will be called when a user selects the scenario to run.
  5. Optionally, implement the Init and/or Run overrides to provide a custom implementation.

The sample below is provided in the .\UICatalog\Scenarios directory as a generic sample that can be copied and re-named:


namespace UICatalog {
	[ScenarioMetadata (Name: "Generic", Description: "Generic sample - A template for creating new Scenarios")]
	[ScenarioCategory ("Controls")]
	class MyScenario : Scenario {
		public override void Setup ()
		{
			// Put your scenario code here, e.g.
			Win.Add (new Button () { 
Text = "Press me!", 
				X = Pos.Center (),
				Y = Pos.Center (),
				Clicked = () => MessageBox.Query (20, 7, "Hi", "Neat?", "Yes", "No")
			});
		}
	}
}

Scenario provides Win, a Window object that provides a canvas for the Scenario to operate.

The default Window shows the Scenario name and supports exiting the Scenario through the Esc key.

screenshot

To build a more advanced scenario, where control of the Toplevel and Window is needed (e.g. for scenarios using MenuBar or StatusBar), simply use Application.Top per normal Terminal.Gui programming, as seen in the Notepad scenario.

For complete control, the Init and Run overrides can be implemented. The base.Init creates Win. The base.Run simply calls Application.Run(Application.Top).

Contribution Guidelines

  • Provide a terse, descriptive Name for Scenarios. Keep them short.
  • Provide a clear Description.
  • Comment Scenario code to describe to others why it's a useful Scenario.
  • Annotate Scenarios with [ScenarioCategory] attributes. Minimize the number of new categories created.
  • Use the Bug Repo Category for Scenarios that reproduce bugs.
    • Include the Github Issue # in the Description.
    • Once the bug has been fixed in develop submit another PR to remove the Scenario (or modify it to provide a good regression test/sample).
  • Tag bugs or suggestions for UI Catalog as Terminal.Gui Github Issues with "UICatalog: ".