[BeefWellington]

I may be showing my age here, but I think most people would expect a TUI to provide arrow key navigation and highlight by default, which is not demonstrated.

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.

[cek]

Terminal.Gui maintainer here...

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!

[styx31]

Perhaps you should also have made a demo video with keyboard only, with key pressed displayed on screen?

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.

[BeefWellington]

That's good to hear but I have to wonder then why the demo is seemingly exclusively demonstrating the mouse?

[cek]

Because I (apparently incorrectly) assumed a lot of people would appreciate the fact the mouse works so well.

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 ;-).

[colanderman]

As a user of Terminal.Gui I appreciate that there is also solid mouse support. It serves my particular application well.

[moron4hire]

Maybe it's a lot harder to show flow through the UI with just keyboard entry. The mouse pointer trailing through the frame animates how the user's attention is moving through the UI.

[alkonaut]

Are there any specific examples from the demo that don't show proper highlights (i.e. that don't look exactly like e.g. TurboPascal, Norton Commander or Linux menuconfig in terms of hints/highlight/focus)?

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.

[cek]

This is NOT "literally a port of an older curses lib to the latest .net". It is a complete API for building terminal UI applications using .NET that leverages curses under the covers when running in a non-Windows environment (on Windows it uses the native Windows console APIs).

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 ;-).

[alkonaut]

I only meant port of a curses based lib as in “This is an updated version of gui.cs that Miguel wrote for mono-curses in 2007”

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.

[cek]

Terminal.Gui really has become "WinForms-in-the-terminal". A lot of the capabilities borrow from WinForms and other popular GUI frameworks. We're not afraid of plagerising.

Check out the list of built-in View classes:

https://gui-cs.github.io/Terminal.Gui/articles/views.html

I'll work on updating the history section of the README to make this more clear.

[lostmsu]

> Simply mapping Gui -> TUI isn't really a good user experience IME

Nitpicking: gaming console GUIs are very accessible. I'd take them as a great starting point.