Live data from Hacker News

Terminal.Gui: A Cross Platform Terminal UI Toolkit for .NET

github.com

41–50 of 83 posts

Re: Terminal.Gui: A Cross Platform Terminal UI Toolkit for .NET

#41
post #29

Earlier quoted context omitted.

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

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

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

Re: Terminal.Gui: A Cross Platform Terminal UI Toolkit for .NET

#42
post #36

On the C++ front, I've been using this and love it - https://github.com/ArthurSonzogni/FTXUI - it also has wasm target, so may target the web. I'm regular Far Commander on Windows, and Midnight Commander, also known as mc on Linux/OSX. In fact my "Command-Prompt" on Windows is always FAR (this comes with certain limitations, but I'm so used to it, I can't do my normal work without it). I could never get into the Expl…

Looks great, thanks!

As for Orthodox File Managers, I'm in the same camp and I could never understand how people can be productive with bare Explorer window. Most operations of files and directories require more work (keystrokes/mouse movements) than in OFMs. Not to mention things like having a quick look into any text file, for example (F3-Esc) as opposed to double clicking - running an external viewer - closing it. Practically everything in OFMs can be done faster.

Re: Terminal.Gui: A Cross Platform Terminal UI Toolkit for .NET

#43
post #39
post #7

Earlier quoted context omitted.

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 syste…

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" bas…

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.

Re: Terminal.Gui: A Cross Platform Terminal UI Toolkit for .NET

#44
post #36

On the C++ front, I've been using this and love it - https://github.com/ArthurSonzogni/FTXUI - it also has wasm target, so may target the web. I'm regular Far Commander on Windows, and Midnight Commander, also known as mc on Linux/OSX. In fact my "Command-Prompt" on Windows is always FAR (this comes with certain limitations, but I'm so used to it, I can't do my normal work without it). I could never get into the Expl…

Looks great, thanks! As for Orthodox File Managers, I'm in the same camp and I could never understand how people can be productive with bare Explorer window. Most operations of files and directories require more work (keystrokes/mouse movements) than in OFMs. Not to mention things like having a quick look into any text file, for example (F3-Esc) as opposed to double clicking - running an external viewer - closing it.…

The main way I navigate these days is global search through Everything. File operations apart from saving and opening files are extremely rare, and I just do them from PowerShell via command history.

Re: Terminal.Gui: A Cross Platform Terminal UI Toolkit for .NET

#45

Earlier quoted context omitted.

Tab navigation and hotkeys are enabled by default. It's easy to add other keyboard overrides as well. You do not need a mouse to use it.

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.

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

Re: Terminal.Gui: A Cross Platform Terminal UI Toolkit for .NET

#48
post #44

Earlier quoted context omitted.

Looks great, thanks! As for Orthodox File Managers, I'm in the same camp and I could never understand how people can be productive with bare Explorer window. Most operations of files and directories require more work (keystrokes/mouse movements) than in OFMs. Not to mention things like having a quick look into any text file, for example (F3-Esc) as opposed to double clicking - running an external viewer - closing it.…

The main way I navigate these days is global search through Everything. File operations apart from saving and opening files are extremely rare, and I just do them from PowerShell via command history.

Do you happen to use "F7 History" [1] which is based on `Out-ConsoleGridView`, which, in-turn is built on Terminal.Gui?

If not, why not? (Because I'd love to make it even better).

[1] https://github.com/gui-cs/F7History

Re: Terminal.Gui: A Cross Platform Terminal UI Toolkit for .NET

#49
post #39

Earlier quoted context omitted.

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" bas…

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 anythi…

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.

Re: Terminal.Gui: A Cross Platform Terminal UI Toolkit for .NET

#50
post #28

About four years ago I had a meeting with a distributor who had terminal app and wanted to move it to a web based app. Everyone had the keyboard shortcuts memorized and did a quick demo that the refresh rate of the monitor was not fast (only slightly joking here) enough to go through all the screens they did for each task they had to do in this system. Interesting that this could be a useful replacement for something…

A state agency contracted us to replace their old green screen CSR system with a web based one. The existing CSRs hated the new system because they could get work done faster using the keystroke drive system they were accustomed to using. The client however was fine with this outcome because that job had very high turnover and it took too long for new employees to get to the point where they were highly productive. The handful of long term employees asked if they could have both systems running side by side but the client didn't want to have to support both. At least as state employees, this resetting of their productivity to that of new employees didn't impact their salary level that was based mostly on seniority.
Post reply on HN