Terminal.Gui/docfx/docs/newinv2.md

Terminal.Gui v2

Check out this Discussion: https://github.com/gui-cs/Terminal.Gui/discussions/2448

• Modern Look & Feel - Apps built with Terminal.Gui now feel modern thanks to these improvements:
  • TrueColor support - 24-bit color support for Windows, Mac, and Linux. Legacy 16-color systems are still supported, automatically. See TrueColor for details.
  • User Configurable Color Themes - See Color Themes for details.
  • *Enhanced Unicode/Wide Character support *- Terminal.Gui now supports the full range of Unicode/wide characters. See Unicode for details.
  • Line Canvas - Terminal.Gui now supports a line canvas enabling high-performance drawing of lines and shapes using box-drawing glyphs. LineCanvas provides auto join, a smart TUI drawing system that automatically selects the correct line/box drawing glyphs for intersections making drawing complex shapes easy. See Line Canvas for details.
  • Enhanced Borders and Padding - Terminal.Gui now supports a Border, Margin, and Padding property on all views. This simplifies View development and enables a sophisticated look and feel. See Padding for details.
  • Modern File Dialog - Terminal.Gui now supports a modern file dialog that includes icons (in TUI!) for files/folders, search, and a `TreeView``. See FileDialog for details.
• Configuration Manager - Terminal.Gui now supports a configuration manager enabling library and app settings to be persisted and loaded from the file system. See Configuration Manager for details.
• Simplified API - The entire library has been reviewed and simplified. As a result, the API is more consistent and uses modern .NET API standards (e.g. for events). This refactoring resulted in the removal of thousands of lines of code, better unit tests, and higher performance than v1. See Simplified API for details.
• View Lifetime Management is Now Deterministic - In v1 the rules ofr lifetime management of View objects was unclear and led to non-dterministic behavior and hard to diagnose bugs. This was particularly acute in the behavior of Application.Run. In v2, the rules are clear and the code and unit test infrastructure tries to enforce them.
  • View and all subclasses support IDisposable and must be disposed (by calling view.Dispose ()) by whatever code owns the instance when the instance is longer needed.
  • 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 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 interogate 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> ().
    • 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.

...