Simply mapping Gui -> TUI isn't really a good user experience IME. The terminal should generally be keyboard-first/designed with keyboard-only in mind.
We view the mouse as optional. We want the mouse to work perfectly, but it should be optional. If any of the library doesn't work well with just a keyboard, please submit an issue!
It could have helped showcasing that the UI works perfectly with keyboard.
I agree that the demo gif tends to say that this library is mostly intended for mouse usage.
Also, because getting the mouse to work well (across Windows, Mac, Linux, etc...) is freaking hard and the Terminal.Gui team is proud of their work ;-).
This isn't an emulation of a mouse gui stuck in a terminal, this is literally a port of an older curses lib to the latest .net, so it doesn't feel like it should have any unnecessary influence from desktop ui systems at all.
For completeness, Terminal.Gui is built on top of a "Console Abstraction Layer" (CAL; I just invented that term), via the "ConsoleDriver" base class. There are four subclasses provided:
- CursesDriver: Uses curses and is the default on Linux/Mac.
- WindowsDriver: Uses the Windows console API and is the default on Windows (only works on Windows)
- NetDriver: Uses the .NET console API and works on all platforms
- FakeDriver: Used for unit testing.
NetDriver is the slowest. WindowsDriver is the fastest. CursesDriver is the biggest bugfarm ;-).
so it would be natural that it’s still a normal keyboard-first terminal ui lib because gui.cs was. Would be pretty strange if this took a whole different direction or scope and became a WinForms-in-the-terminal. Can’t see anything in the video, source or history that suggests that it’s anything but a terminal ui only adapted for more targets other than curses.
Nitpicking: gaming console GUIs are very accessible. I'd take them as a great starting point.
