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 Explorer, and only use it in rare cases.
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.
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.
Looking at the demo images, I must admit that I have some traumatic memories associated with that shade of blue on a console :) Mostly from fiddling with BIOS settings etc.
My only experience with C# is in using the Unity 3D game engine. Now with a console apps ecosystem, cross-platform focus, GUI libraries, machine learning stuff, mobile apps. It's becoming an attractive prospect by the day.
And to me the opposite - Turbo/Borland Pascal/C++, or the E3 editor. Okay, turns out blue is not great color for you - but that was the "dark" theme at the time.
C# the language has always felt like "Java, but better".
Now with .NET Core embracing cross platform and maturing nicely, it feels like the whole ecosystem can be described as "Java, but better". On Windows, it's already been there for a decade or more, but the label never felt right when hosting on Linux meant using an alternative runtime like Mono.
I remember Xtree back in 1990. Oh boy, do I feel old. I still miss the lightning fast navigation using Xtree and NC afterwards. I used NC till the long filenames were an issue and though I know it supported it later on I just moved on to crappier trends. One recent trend is to completely disempower users by obscuring the file system away.
F# is even better. It is an amazing fun and productive language to work in. At the end of the day a language is just a language, but much the a keyboard some are more comfortable than others. I find F# very comfortable. C# is also very nice to work in. C# is probably a better choice as you spend less novelty points.
Blue background was a very common convention for DOS TUI. I'm not sure which app started it, but it was seen in MS-DOS editor / QBASIC; Norton Commander and its numerous clones; Turbo/Borland Pascal and C++; Microsoft C, Pascal and VB for DOS; FoxBASE / FoxPro; and so on.
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 like that in a modern language.
I remember the early 90s, when the women at the local groceries store (Aldi Germany) were equally as fast when typing in the prices of the articles using just a numpad keyboard on the register - before barcode scanners were a thing. Today it seems surreal or special, but back then you were basically considered a trained professional on the checkout counter.
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.
In my country (Brazil) I sporadically meet people using TUI-based systems. Mostly COBOL but also a good amount of Clipper (or Harbour, maybe?).
I'm also aware of a couple of companies maintaining systems in Harbour and my parents use a web app written in Pascal -- I could tell by the error messages, which are extremely rare btw; the system is very stable, despite the frequent changes it goes through thanks to the tax-legislation mess we have here.
I started asking people about which type of system they prefer: those old dinosaurs or the good-looking, modern ones? 100% voted for the former. Why? "It's fast", they answer.
Some say it's because "they learned to work on those older systems and now are resisting to change". But this is simply false: even younger professionals, who grew using GUIs and web apps, prefer TUIs when it comes to get stuff done.
Such interfaces are also easier to develop. Then, I believe it would be a win-win if TUIs were widely readopted: happier users, systems cheaper to design, build and test.
It would be more interesting to dive down and figure out what exactly the users like more about TUI. Just speed alone can't be it, because e.g. WinXP-era UI is blazing fast on modern hardware (and was plenty fast even back then). And if we know what it is, we can build GUIs that are just as efficient, but that also offer e.g. better text rendering etc compared to TUI.
I once had an interesting experience migrating users from a TUI to a GUI app, ~20 years ago. In that case, after watching them work for a while and asking some questions, the takeaway was that they really wanted the flow to be 100% keyboard-based. Which the GUI apps nominally provided (back then; less so these days), but all too often the correct tab order etc is ignored in practice, making it very difficult to use.
I made sure design the GUI with keyboard in mind, and that common patterns they've learned from TUI would still work. For example, the TUI had a textbox above a listbox, and it was common for users to press arrow-down to navigate from the textbox to the first item in the list, and arrow-up to navigate from the list back into the textbox. This isn't normal behavior for GUI, but I coded it in anyway.
> It would be more interesting to dive down and figure out what exactly the users like more about TU
Indeed. When they say "it's fast", I don't read it simply as "the program is fast". They get their stuff done faster, and the program is simply a tool -- if further speed can be achieved with something else, so be it. It doesnt even need to be software.
However, I still think TUIs are in a better position due to lower development and maintainance costs. This can be achieved by GUI frameworks, for sure. But TUIs tend to be terser, and their natural limitations become an advantage when they make certain sorts of bullcrap (animations, for instance) undoable. I believe this contributes to long-term stability, as developers spend way less time dealing with useless requirements.
> the takeaway was that they really wanted the flow to be 100% keyboard-based
Good that you could draw such conclusion. I do think we should rely more on observation to find out what users need, as opposed to what they _say_ they need. I know this sounds condescending, but I dont mean that. I just believe thay it's hard for them to identify and verbalize some critical factors for their success and they need some mediation.
I also feel upset about the keyboard as a second-class citizen in modern systems. There's this UX design school of thought portraying users as creatures of extremely limited working memory, who can't even remember what they wanted when they clicked the option, and therefore need infantilized interfaces full of pictures and colorful buttons because they won't be able to memorize a handful of keyboard combinations
You need to do both questions and observations, IMO, and iterate between the two. Answers give you hypotheses that can then be verified by observation; if just observing, small things can slip by if you don't know to watch for them in advance.
Most of the time the app really is fast. These old cobol apps have character limits per a screen for the amount of code you can use. Imagine each screen being like 200 lines of code with some raw storage behind the scenes. I had to performance tune a 3270 (mainframe) emulator once in c# and it took 2-3 weeks to get the c# app on a xeon processor to have to start waiting on the mainframe. Also nothing, ever, ever, timed out, ever.
I'm surprised keyboard shortcuts are not more normal in b2b web apps for this exact reason. There's no technical limitation. Bloomberg probably has the most profitable "terminal" UI, supports the same keyboard shortcuts it had a generation ago, and the whole thing was built on webkit last I heard.
I've heard the same about some day-trading companies, or anyone dealing with customers/clients and has to lots to input/navigate - they still keep old terminals to good use.
Great, there's some terminal programs I'd have preferred to code in C# but did in Python instead as I didn't know this exists.
First I thought resizing doesn't work but it seems it's only an issue with kitty, on alacritty it works as expected, in case anyone else is wondering the same.
> A possible BBS with door games like ZMachine and a sea-faring game I'm writing in a private repo, (top secret!) which used to have the only test harness solution containing both the source and test repos.
My hot take would be to implement a lot of LambdaMOO [1]... in C#... because I like the grammar and parser [1], and I like reflection and attributes... and... Well, it's a thing I'd just like to exist.
How people get the mouse working in the terminal is one of those things I've always wondered how they do it, but never look into it because then the magic is gone. As a daily software engineer it's nice to have some things remain as magic
AIUI, there's a special mode for the running app to grab mouse input in the terminal. Otherwise, the mouse is just used for copy&paste. This applies to both Windows and Linux btw.
I'm expecting a terminal UI to be primarily keyboard-driven, but the demo uses the mouse a lot. Anyone having experience with this library and able to confirm keyboard navigation is good by default?
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.
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!
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 ;-).
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.
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.
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 ;-).
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.
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.
What? No Blazor support? No mobile support? (Joke)
I think console UIs are good for a sweet spot where you need a "just good enough" UI that you can whip up in a few minutes. I hope this meets the sweet spot.
iirc most MUDs use telnet, so any user can use whichever client they prefer - I'm sure there's ways to have xterm.js use telnet. There's this project that is a MUD using Telnet written in C#: https://github.com/cmackles/MudSharp
Yes, thanks, I'm aware most MUDs use telnet, but in my opinion, that's a barrier to entry to most users.
And thanks for the link, but it makes me sad to see a repro that was last updated 5 years ago.
> I'm sure there's ways to have xterm.js use telnet.
You have to have a server in-between to do straight telnet. (You can't do a vanilla TCP/IP connection from the browser.)
So I'd like to have WebSockets + xterm.js taking the place of telnet + terminal...
And then I'd like a .Net API that looks like curses, or like this GUI, or something... and that persists the console (like tmux or something), so if the user re-connects, they get their view restored "automagically."
I'm going to use the heck out of this but I can't even touch it until I know exactly why it's named Terminal._G_ui. I figured an explanation would be in the first sentence. The G better stand for something super clever :)
I've heard of GUI's and I've heard of TUI's but never TGUI's. I was expecting some kind of hybrid thing even though I couldn't begin to imagine what it would be. I'm just saying, there are no graphics.
Trying to give you a fairly complete answer: It's a .NET library, the prerequisites are the same as any .NET library.
If you want to write code in .NET you will need to install the .NET SDK.
If you just want to run an application written in .NET... it depends. Apps can be shipped with a built-in .NET runtime ("self-contained"), which makes them bigger on disk but they don't need any prerequisites installed. Apps can also be shipped without a .NET runtime ("framework-dependent"), in which case the user needs to have a shared runtime installed to run the app.
The Terminal.Gui library itself doesn't provide any special means for dealing with state. However, the full power of .NET Core is available for devs to do whatever they please.
It's just the naming convention of .NET stuff, e.g. someone else has a NuGet package for "Terminal.Connector" and someone else has one for "
Rebex.Terminal.SerialPort" but none of these are related. I will say normally you'd stick some sort of group/developer/company identifier in front though like the Rebex example has but it's not a hard and fast rule.
Pretty sure this is a Casey Muratori reference. Doesn't really apply to the current project as it's a UI on top of the existing terminal rather than a whole new terminal.
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 Explorer, and only use it in rare cases.