mirror of
https://github.com/gui-cs/Terminal.Gui.git
synced 2025-12-31 02:08:03 +01:00
Merge pull request #567 from tig/project_readme
added contribution guidelines, project layout docs, etc...
This commit is contained in:
Charlie Kindel
GitHub
76
CODE_OF_CONDUCT.md
Normal file
76
CODE_OF_CONDUCT.md
Normal file
@@ -0,0 +1,76 @@
|
||||
# Contributor Covenant Code of Conduct
|
||||
|
||||
## Our Pledge
|
||||
|
||||
In the interest of fostering an open and welcoming environment, we as
|
||||
contributors and maintainers pledge to making participation in our project and
|
||||
our community a harassment-free experience for everyone, regardless of age, body
|
||||
size, disability, ethnicity, sex characteristics, gender identity and expression,
|
||||
level of experience, education, socio-economic status, nationality, personal
|
||||
appearance, race, religion, or sexual identity and orientation.
|
||||
|
||||
## Our Standards
|
||||
|
||||
Examples of behavior that contributes to creating a positive environment
|
||||
include:
|
||||
|
||||
* Using welcoming and inclusive language
|
||||
* Being respectful of differing viewpoints and experiences
|
||||
* Gracefully accepting constructive criticism
|
||||
* Focusing on what is best for the community
|
||||
* Showing empathy towards other community members
|
||||
|
||||
Examples of unacceptable behavior by participants include:
|
||||
|
||||
* The use of sexualized language or imagery and unwelcome sexual attention or
|
||||
advances
|
||||
* Trolling, insulting/derogatory comments, and personal or political attacks
|
||||
* Public or private harassment
|
||||
* Publishing others' private information, such as a physical or electronic
|
||||
address, without explicit permission
|
||||
* Other conduct which could reasonably be considered inappropriate in a
|
||||
professional setting
|
||||
|
||||
## Our Responsibilities
|
||||
|
||||
Project maintainers are responsible for clarifying the standards of acceptable
|
||||
behavior and are expected to take appropriate and fair corrective action in
|
||||
response to any instances of unacceptable behavior.
|
||||
|
||||
Project maintainers have the right and responsibility to remove, edit, or
|
||||
reject comments, commits, code, wiki edits, issues, and other contributions
|
||||
that are not aligned to this Code of Conduct, or to ban temporarily or
|
||||
permanently any contributor for other behaviors that they deem inappropriate,
|
||||
threatening, offensive, or harmful.
|
||||
|
||||
## Scope
|
||||
|
||||
This Code of Conduct applies both within project spaces and in public spaces
|
||||
when an individual is representing the project or its community. Examples of
|
||||
representing a project or community include using an official project e-mail
|
||||
address, posting via an official social media account, or acting as an appointed
|
||||
representative at an online or offline event. Representation of a project may be
|
||||
further defined and clarified by project maintainers.
|
||||
|
||||
## Enforcement
|
||||
|
||||
Instances of abusive, harassing, or otherwise unacceptable behavior may be
|
||||
reported by contacting the project team at miguel@gnome.org. All
|
||||
complaints will be reviewed and investigated and will result in a response that
|
||||
is deemed necessary and appropriate to the circumstances. The project team is
|
||||
obligated to maintain confidentiality with regard to the reporter of an incident.
|
||||
Further details of specific enforcement policies may be posted separately.
|
||||
|
||||
Project maintainers who do not follow or enforce the Code of Conduct in good
|
||||
faith may face temporary or permanent repercussions as determined by other
|
||||
members of the project's leadership.
|
||||
|
||||
## Attribution
|
||||
|
||||
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
|
||||
available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
|
||||
|
||||
[homepage]: https://www.contributor-covenant.org
|
||||
|
||||
For answers to common questions about this code of conduct, see
|
||||
https://www.contributor-covenant.org/faq
|
||||
100
CONTRIBUTING.md
Normal file
100
CONTRIBUTING.md
Normal file
@@ -0,0 +1,100 @@
|
||||
# Contributing to Terminal.Gui
|
||||
|
||||
We welcome contributions from the community. See [Issues](https://github.com/migueldeicaza/gui.cs/issues) for a list of open [bugs](https://github.com/migueldeicaza/gui.cs/issues?q=is%3Aopen+is%3Aissue+label%3Abug) and [enhancements](https://github.com/migueldeicaza/gui.cs/issues?q=is%3Aopen+is%3Aissue+label%3Aenhancement). Contributors looking for something fun to work on should look at issues taged as:
|
||||
|
||||
- [good first issue](https://github.com/migueldeicaza/gui.cs/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22)
|
||||
- [up for grabs](https://github.com/migueldeicaza/gui.cs/issues?q=is%3Aopen+is%3Aissue+label%3Aup-for-grabs)
|
||||
- [help wanted](https://github.com/migueldeicaza/gui.cs/issues?q=is%3Aopen+is%3Aissue+label%3Aup-for-grabs)
|
||||
|
||||
## Coding Style
|
||||
|
||||
**Terminal.Gui** follows the [Mono Coding Guidelines](https://www.mono-project.com/community/contributing/coding-guidelines/). `../.editorconfig` uses Visual Studio to help enforce these.
|
||||
|
||||
## User Experience Tenets
|
||||
|
||||
**Terminal.Gui**, as a UI framework, heavily influences how console graphical user interfaces (GUIs) work. We use the following [tenets](https://ceklog.kindel.com/2020/02/10/tenets/) to guide us:
|
||||
|
||||
*NOTE: Like all tenets, these are up for debate. If you disagree, have questions, or suggestions about these tenets and guideliens submit an Issue using the [design](https://github.com/migueldeicaza/gui.cs/issues?q=is%3Aopen+is%3Aissue+label%3Adesign) tag.*
|
||||
|
||||
1. **Honor What's Come Before**. The Mac and Windows OS's have well established GUI idioms that are mostly consistent. We adhere to these versus inventing new ways for users to do things. For example, **Terminal.Gui** adopts the `ctrl/command-c`, `ctrl/command-v`, and `ctrl/command-x` keyboard shortcuts for cut, copy, and paste versus defining new shortcuts.
|
||||
2. **Consistency Matters**. Common UI idioms should be consistent across the GUI framework. For example, `ctrl/command-q` quits/exits all modal views. See [Issue #456](https://github.com/migueldeicaza/gui.cs/issues/456) as a counter example that should be fixed.
|
||||
3. **Honor the OS, but Work Everywhere**. **Terminal.Gui** is cross-platform, but we support taking advantage of a platform's unique advantages. For example the Windows Console API is richer than the Unix API in terms of keyboard handling. Thus, in Windows pressing the `alt` key in a **Terminal.Gui** app will activate the `MenuBar`, but in Unix the user has to press the full hotkey (e.g. `alt-f`) or `F9`.
|
||||
4. **Keyboard first, Mouse also**. Users use consoles primarily with the keyboard; **Terminal.Gui** is optimized for getting stuff done without using the mouse. However, as a GUI framework, the mouse is essential, thus we strive to ensure that everything also works via the mouse.
|
||||
|
||||
## Public API Tenets & Guidelines
|
||||
|
||||
**Terminal.Gui** provides an API that is used by many. As the project evolves contributors should follow these [tenets](https://ceklog.kindel.com/2020/02/10/tenets/) to ensure consistency and backwards compatabiltiy.
|
||||
|
||||
*NOTE: Like all tenets, these are up for debate. If you disagree, have questions, or suggestions about these tenets and guideliens submit an Issue using the [design](https://github.com/migueldeicaza/gui.cs/issues?q=is%3Aopen+is%3Aissue+label%3Adesign) tag.*
|
||||
|
||||
1. **Stand on the shoulders of giants.** Follow the [Microsoft .NET Framework Design Guidelines](https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/) where appropriate.
|
||||
2. **Don't Break Existing Stuff.** Avoid breaking changes to user behavior or the public API; instead, figure out how to implement new functionality in a parallel way. If a breaking change can't be avoided, follow the guidelines below.
|
||||
3. **Fail-fast.** Fail-fast makes bugs and failures appear sooner, leading to a higher-quality framework and API.
|
||||
4. **Standards Reduce Complexity**. We strive to adopt standard API idoms because doing so reduces complexity for users of the API. For example, see Tenet #1 above. A counter example is [Issue #447](https://github.com/migueldeicaza/gui.cs/issues/447).
|
||||
|
||||
### Include API Documentation
|
||||
|
||||
Great care has been provided thus far in ensuring **Terminal.Gui** has great [API Documentation](https://migueldeicaza.github.io/gui.cs/api/Terminal.Gui/Terminal.Gui.html). Contributors have a responsiblity for continously improving the API Documentation.
|
||||
|
||||
- All public APIs must have clear, concise, and complete documentation in the form of [XML Documentation](https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/xmldoc/).
|
||||
- Keep the `<summary></summary>` terse.
|
||||
- Use `<see cref=""/>` liberally to cross-link topics.
|
||||
- Use `<remarks></remarks>` to add more context and explaination.
|
||||
- For complex topics, provide conceptual documentation in the `docfx/articles` folder as a `.md` file. It will automatically get picked up and be added to [Conceptual Documenation](https://migueldeicaza.github.io/gui.cs/articles/index.html).
|
||||
- Use proper English and good grammar.
|
||||
|
||||
### Defining Events
|
||||
|
||||
The [Microsoft .NET Framework Design Guidelines](https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/) provides these guideliens for defining events:
|
||||
|
||||
> Events always refer to some action, either one that is happening or one that has occurred. Therefore, as with methods, events are named with verbs, and verb tense is used to indicate the time when the event is raised.
|
||||
>
|
||||
> ✔️ DO name events with a verb or a verb phrase.
|
||||
>
|
||||
> Examples include Clicked, Painting, DroppedDown, and so on.
|
||||
>
|
||||
> ✔️ DO give events names with a concept of before and after, using the present and past tenses.
|
||||
>
|
||||
> For example, a close event that is raised before a window is closed would be called Closing, and one that is raised after the window is closed would be called Closed.
|
||||
>
|
||||
> ❌ DO NOT use "Before" or "After" prefixes or postfixes to indicate pre- and post-events. Use present and past tenses as just described.
|
||||
>
|
||||
> ✔️ DO name event handlers (delegates used as types of events) with the "EventHandler" suffix, as shown in the following example:
|
||||
>
|
||||
> public delegate void ClickedEventHandler(object sender, ClickedEventArgs e);
|
||||
>
|
||||
> ✔️ DO use two parameters named sender and e in event handlers.
|
||||
>
|
||||
> The sender parameter represents the object that raised the event. The sender parameter is typically of type object, even if it is possible to employ a more specific type.
|
||||
>
|
||||
> ✔️ DO name event argument classes with the "EventArgs" suffix.
|
||||
|
||||
We are not currently consistent along these lines in `Terminal.Gui` at all. This leads to friction for adopters and bugs. As we take on fixing this we use the following guidelines:
|
||||
|
||||
1. We follow the naming guidelines provided in https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-type-members?redirectedfrom=MSDN
|
||||
2. We use the `Action<T>` idiom for internal APIs, not for public APIs. For public APIs we use the `event/EventHandler` model.
|
||||
3. For public APIs, the class that can raise the event will implement:
|
||||
- A `virtual` event raising function, named as `OnEventToRaise`. Typical implementations will simply do a `EventToRaise?.Invoke(this, eventArgs)`.
|
||||
- An `event` as in `public event EventHandler<EventToRaiseArgs> EventToRaise`
|
||||
- Consumers of the event can do `theobject.EventToRaise += (sender, e) => {};`
|
||||
- Sub-classes of the class implementing `EventToRaise` can override `OnEventToRaise` as needed.
|
||||
4. Where possible, a subclass of `EventArgs` should be provided and the old and new state should be included. By doing this, event handler methods do not have to query the sender for state.
|
||||
|
||||
See also: https://www.codeproject.com/Articles/20550/C-Event-Implementation-Fundamentals-Best-Practices
|
||||
|
||||
### Defining new `View` classes
|
||||
|
||||
- Support parameterless constructors (see [Issue 102](Parameterless constructors #102)). Do not require callers to use a parametrized constructor except when forcing `Absolute Layout`).
|
||||
- Avoid doing initialization via constructors. Instead use a property so consumers can use object initialization (e.g. `var foo = new Foo() { a = b };`).
|
||||
- Ensure the `UICatalog` demo for the new class illustrates both `Absolutle Layout` and `Computed Layout`.
|
||||
|
||||
## Breaking Changes to User Behavior or the Public API
|
||||
|
||||
- Tag all pull requests that cause breaking changes to user behavior or the public API with the [breaking-change](https://github.com/migueldeicaza/gui.cs/issues?q=is%3Aopen+is%3Aissue+label%3Abreaking-change) tag. This will help project maintainers track and document these.
|
||||
- Add a `<remark></remark>` to the XML Documentation to the code describing the breaking change. These will get picked up in the [API Documentation](https://migueldeicaza.github.io/gui.cs/api/Terminal.Gui/Terminal.Gui.html).
|
||||
|
||||
## Examples & Tests
|
||||
|
||||
**Terminal.Gui** does an automated unit or regression test suite ([please feel free to help build one](https://github.com/migueldeicaza/gui.cs/issues/566)). Until such a suite is available, the best we have is the [UICatalog](https://github.com/migueldeicaza/gui.cs/tree/master/UICatalog) sample app.
|
||||
|
||||
When adding new functionality, fixing bugs, or changing things, please either add a new `Scenario` to **UICatalog** or update an existing `Scenario` to fully illustrate your work and provide a test-case.
|
||||
128
README.md
128
README.md
@@ -4,9 +4,9 @@
|
||||
[](LICENSE)
|
||||
[](https://gitter.im/mono/mono?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge) - The Mono Channel room
|
||||
|
||||
# Terminal.Gui - Terminal UI toolkit for .NET
|
||||
# Terminal.Gui - Terminal GUI toolkit for .NET
|
||||
|
||||
A simple UI toolkit for .NET, .NET Core, and Mono that works on Windows, the Mac, and Linux/Unix.
|
||||
A simple toolkit for buiding console GUI apps for .NET, .NET Core, and Mono that works on Windows, the Mac, and Linux/Unix.
|
||||
|
||||
|
||||
|
||||
@@ -18,8 +18,8 @@ The *Terminal.Gui* toolkit contains various controls for building text user inte
|
||||
* [CheckBox](https://migueldeicaza.github.io/gui.cs/api/Terminal.Gui/Terminal.Gui.CheckBox.html)
|
||||
* [ComboBox](https://migueldeicaza.github.io/gui.cs/api/Terminal.Gui/Terminal.Gui.ComboBox.html)
|
||||
* [Dialog](https://migueldeicaza.github.io/gui.cs/api/Terminal.Gui/Terminal.Gui.Dialog.html)
|
||||
* [OpenDialog](https://migueldeicaza.github.io/gui.cs/api/Terminal.Gui/Terminal.Gui.OpenDialog.html)
|
||||
* [SaveDialog](https://migueldeicaza.github.io/gui.cs/api/Terminal.Gui/Terminal.Gui.SaveDialog.html)
|
||||
* [OpenDialog](https://migueldeicaza.github.io/gui.cs/api/Terminal.Gui/Terminal.Gui.OpenDialog.html)
|
||||
* [SaveDialog](https://migueldeicaza.github.io/gui.cs/api/Terminal.Gui/Terminal.Gui.SaveDialog.html)
|
||||
* [FrameView](https://migueldeicaza.github.io/gui.cs/api/Terminal.Gui/Terminal.Gui.FrameView.html)
|
||||
* [Hex viewer/editor](https://migueldeicaza.github.io/gui.cs/api/Terminal.Gui/Terminal.Gui.HexView.html)
|
||||
* [Label](https://migueldeicaza.github.io/gui.cs/api/Terminal.Gui/Terminal.Gui.Label.html)
|
||||
@@ -36,7 +36,7 @@ The *Terminal.Gui* toolkit contains various controls for building text user inte
|
||||
* [StatusBar](https://migueldeicaza.github.io/gui.cs/api/Terminal.Gui/Terminal.Gui.StatusBar.html)
|
||||
* [Window](https://migueldeicaza.github.io/gui.cs/api/Terminal.Gui/Terminal.Gui.Window.html)
|
||||
|
||||
In addition, a complete Xterm/Vt100 terminal emulator that you can embed is now part of [XtermSharp](https://github.com/migueldeicaza/XtermSharp/blob/master/GuiCsHost/TerminalView.cs) - you just need to pull the `TerminalView` linked here into your project.
|
||||
In addition, a complete Xterm/Vt100 terminal emulator that you can embed is now part of [XtermSharp](https://github.com/migueldeicaza/XtermSharp/blob/master/GuiCsHost/TerminalView.cs) - you just need to pull [`TerminalView.cs`](https://github.com/migueldeicaza/XtermSharp/blob/master/GuiCsHost/TerminalView.cs) into your project.
|
||||
|
||||
### Features
|
||||
|
||||
@@ -70,6 +70,12 @@ Currently **Terminal.Gui** has support for [ncurses](https://github.com/miguelde
|
||||
|
||||
You can force the use of `System.Console` on Unix as well; see `Core.cs`.
|
||||
|
||||
### Design
|
||||
|
||||
See the [`Terminal.Gui/` README](https://github.com/migueldeicaza/gui.cs/tree/master/Terminal.Gui) for an overview of how the library is structured. The [Conceptual Documentation](https://migueldeicaza.github.io/gui.cs/articles/index.html) provides insight into core concepts.
|
||||
|
||||
Debates on architecture and design can be found in Issues tagged with [design](https://github.com/migueldeicaza/gui.cs/issues?q=is%3Aopen+is%3Aissue+label%3Adesign).
|
||||
|
||||
## Showcase & Examples
|
||||
|
||||
* **UI Catalog** - The [UI Catalog project](https://github.com/migueldeicaza/gui.cs/tree/master/UICatalog) provides an easy to use and extend sample illustrating the capabilities of **Terminal.Gui**. Run `dotnet run` in the `UICatalog` directory to run the UI Catalog.
|
||||
@@ -78,9 +84,9 @@ You can force the use of `System.Console` on Unix as well; see `Core.cs`.
|
||||
|
||||
## Documentation
|
||||
|
||||
* [API documentation](https://migueldeicaza.github.io/gui.cs/api/Terminal.Gui/Terminal.Gui.html)
|
||||
|
||||
* [Overview](https://migueldeicaza.github.io/gui.cs/articles/overview.html) contains the conceptual documentation and a walkthrough of the core concepts of **Terminal.Gui**.
|
||||
* [Overview](https://migueldeicaza.github.io/gui.cs/articles/overview.html)
|
||||
* [Conceptual Documenation](https://migueldeicaza.github.io/gui.cs/articles/index.html)
|
||||
* [API Documentation](https://migueldeicaza.github.io/gui.cs/api/Terminal.Gui/Terminal.Gui.html)
|
||||
|
||||
### Sample Usage
|
||||
|
||||
@@ -88,68 +94,68 @@ You can force the use of `System.Console` on Unix as well; see `Core.cs`.
|
||||
using Terminal.Gui;
|
||||
|
||||
class Demo {
|
||||
static void Main ()
|
||||
{
|
||||
Application.Init ();
|
||||
var top = Application.Top;
|
||||
static void Main ()
|
||||
{
|
||||
Application.Init ();
|
||||
var top = Application.Top;
|
||||
|
||||
// Creates the top-level window to show
|
||||
var win = new Window ("MyApp") {
|
||||
X = 0,
|
||||
Y = 1, // Leave one row for the toplevel menu
|
||||
var win = new Window ("MyApp") {
|
||||
X = 0,
|
||||
Y = 1, // Leave one row for the toplevel menu
|
||||
|
||||
// By using Dim.Fill(), it will automatically resize without manual intervention
|
||||
Width = Dim.Fill (),
|
||||
Height = Dim.Fill ()
|
||||
// By using Dim.Fill(), it will automatically resize without manual intervention
|
||||
Width = Dim.Fill (),
|
||||
Height = Dim.Fill ()
|
||||
};
|
||||
top.Add (win);
|
||||
top.Add (win);
|
||||
|
||||
// Creates a menubar, the item "New" has a help menu.
|
||||
var menu = new MenuBar (new MenuBarItem [] {
|
||||
new MenuBarItem ("_File", new MenuItem [] {
|
||||
new MenuItem ("_New", "Creates new file", NewFile),
|
||||
new MenuItem ("_Close", "", () => Close ()),
|
||||
new MenuItem ("_Quit", "", () => { if (Quit ()) top.Running = false; })
|
||||
}),
|
||||
new MenuBarItem ("_Edit", new MenuItem [] {
|
||||
new MenuItem ("_Copy", "", null),
|
||||
new MenuItem ("C_ut", "", null),
|
||||
new MenuItem ("_Paste", "", null)
|
||||
})
|
||||
});
|
||||
top.Add (menu);
|
||||
var menu = new MenuBar (new MenuBarItem [] {
|
||||
new MenuBarItem ("_File", new MenuItem [] {
|
||||
new MenuItem ("_New", "Creates new file", NewFile),
|
||||
new MenuItem ("_Close", "", () => Close ()),
|
||||
new MenuItem ("_Quit", "", () => { if (Quit ()) top.Running = false; })
|
||||
}),
|
||||
new MenuBarItem ("_Edit", new MenuItem [] {
|
||||
new MenuItem ("_Copy", "", null),
|
||||
new MenuItem ("C_ut", "", null),
|
||||
new MenuItem ("_Paste", "", null)
|
||||
})
|
||||
});
|
||||
top.Add (menu);
|
||||
|
||||
var login = new Label ("Login: ") { X = 3, Y = 2 };
|
||||
var password = new Label ("Password: ") {
|
||||
X = Pos.Left (login),
|
||||
X = Pos.Left (login),
|
||||
Y = Pos.Top (login) + 1
|
||||
};
|
||||
};
|
||||
var loginText = new TextField ("") {
|
||||
X = Pos.Right (password),
|
||||
Y = Pos.Top (login),
|
||||
Width = 40
|
||||
};
|
||||
var passText = new TextField ("") {
|
||||
Secret = true,
|
||||
X = Pos.Left (loginText),
|
||||
Y = Pos.Top (password),
|
||||
Width = Dim.Width (loginText)
|
||||
};
|
||||
X = Pos.Right (password),
|
||||
Y = Pos.Top (login),
|
||||
Width = 40
|
||||
};
|
||||
var passText = new TextField ("") {
|
||||
Secret = true,
|
||||
X = Pos.Left (loginText),
|
||||
Y = Pos.Top (password),
|
||||
Width = Dim.Width (loginText)
|
||||
};
|
||||
|
||||
// Add some controls,
|
||||
win.Add (
|
||||
// The ones with my favorite layout system
|
||||
login, password, loginText, passText,
|
||||
// The ones with my favorite layout system
|
||||
login, password, loginText, passText,
|
||||
|
||||
// The ones laid out like an australopithecus, with absolute positions:
|
||||
new CheckBox (3, 6, "Remember me"),
|
||||
new RadioGroup (3, 8, new [] { "_Personal", "_Company" }),
|
||||
new Button (3, 14, "Ok"),
|
||||
new Button (10, 14, "Cancel"),
|
||||
new Label (3, 18, "Press F9 or ESC plus 9 to activate the menubar"));
|
||||
// The ones laid out like an australopithecus, with absolute positions:
|
||||
new CheckBox (3, 6, "Remember me"),
|
||||
new RadioGroup (3, 8, new [] { "_Personal", "_Company" }),
|
||||
new Button (3, 14, "Ok"),
|
||||
new Button (10, 14, "Cancel"),
|
||||
new Label (3, 18, "Press F9 or ESC plus 9 to activate the menubar"));
|
||||
|
||||
Application.Run ();
|
||||
}
|
||||
Application.Run ();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@@ -159,10 +165,10 @@ Alternatively, you can encapsulate the app behavior in a new `Window`-derived cl
|
||||
using Terminal.Gui;
|
||||
|
||||
class Demo {
|
||||
static void Main ()
|
||||
{
|
||||
Application.Run<App> ();
|
||||
}
|
||||
static void Main ()
|
||||
{
|
||||
Application.Run<App> ();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@@ -174,11 +180,13 @@ Use NuGet to install the `Terminal.Gui` NuGet package: https://www.nuget.org/pac
|
||||
|
||||
## Running and Building
|
||||
|
||||
* *`Terminal.Gui`* - Build and run using the .NET SDK command line tools (`dotnet build` in the root directory) or with Visual Studio 2019.
|
||||
* Windows - Build and run using the .NET SDK command line tools (`dotnet build` in the root directory) or open `Terminal.Gui.sln` with Visual Studio 2019.
|
||||
* Mac - ???
|
||||
* Linux - (see: https://github.com/migueldeicaza/gui.cs/issues/421)
|
||||
|
||||
## Contributing
|
||||
|
||||
See [Issues](https://github.com/migueldeicaza/gui.cs/issues) for a list of open bugs and enhancements.
|
||||
See [CONTRIBUTING.md](https://github.com/migueldeicaza/gui.cs/blob/master/CONTRIBUTING.md).
|
||||
|
||||
## History
|
||||
|
||||
|
||||
25
Terminal.Gui/README.md
Normal file
25
Terminal.Gui/README.md
Normal file
@@ -0,0 +1,25 @@
|
||||
# Terminal.Gui Project
|
||||
|
||||
Contains all files required to build the **Terminal.Gui** library (and nuget package).
|
||||
|
||||
## Project Folder Structure
|
||||
|
||||
- `Terminal.Gui.sln` - The Visual Studio 2019 solution
|
||||
- `Core/` - Source files for all types that comprise the core building blocks of **Terminal-Gui**
|
||||
- `Application` - A `static` class that provides the base 'application driver'. Given it defines a **Terminal.Gui** application it is both logically and literally (because `static`) a singleton. It has direct dependencies on `MainLoop`, `Events.cs` `NetDriver`, `CursesDriver`, `WindowsDriver`, `Responder`, `View`, and `TopLevel` (and nothing else).
|
||||
- `MainLoop` - Defines `IMainLoopDriver` and implements the and `MainLoop` class.
|
||||
- `ConsoleDriver` - Definition for the Console Driver API.
|
||||
- `Events.cs` - Defines keyboard and mouse related structs & classes.
|
||||
- `PosDim.cs` - Implements **Terminal-Gui's** *Computed Layout* system. These classes have deep dependencies on `View`.
|
||||
- `Responder` - Base class for the windowing class heirachy. Implements support for keyboard & mouse input.
|
||||
- `View` - Derived from `Responder`, the base class for non-modal visual elements such as controls.
|
||||
- `Toplevel` - Drived from `View`, the base class for modal visual elements such as top-level windows and dialogs. Supports the concept of `MenuBar` and `StatusBar`.
|
||||
- `Window` - Drived from `TopLevel`, implements Toplevel views with a visible frame and Title.
|
||||
- `Types/` - A folder (not namespace) containing implementations of `Point`, `Rect`, and `Size` which are ancient versions of the modern `System.Drawing.Point`, `System.Drawing.Size`, and `System.Drawning.Rectangle`.
|
||||
- `ConsoleDrivers/` - Source files for the three `ConsoleDriver`-based drivers: .NET: `NetDriver`, Unix & Mac: `UnixDriver`, and Windows: `WindowsDriver`.
|
||||
- `Views/` - A folder (not namespace) containing the source for all built-in classes that drive from `View` (non-modals).
|
||||
- `Windows/` - A folder (not namespace) containing the source all built-in classes that derive from `Window`.
|
||||
|
||||
## Contributing
|
||||
|
||||
See [CONTRIBUTING.md](https://github.com/migueldeicaza/gui.cs/blob/master/CONTRIBUTING.md).
|
||||
Reference in New Issue
Block a user