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.
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.
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.
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.
I wish it also worked with something like xterm.js, a terminal in the browser.
Either by compiling .Net to WASM... Like Client-Side Blazor does, right?
...or using client-server technology... Like Server-Side Blazor does, right?
We're working on it [1]
[1] https://github.com/Blazor-Console/HACC/blob/main/README.md
> 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.
[1] : https://www.hayseed.net/MOO/manuals/ProgrammersManual.html
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.
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.
I'd like to write MUDs (Multi-User Dungeon games) in C#...
Way to go, team.
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.
Very funny.
If you haven't looked at .NET in a few years, you'd be surprised.
More details: https://www.youtube.com/watch?v=hxM8QmyZXtg
https://www.reddit.com/r/nextfuckinglevel/comments/xa50x1/ma...
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.
But trends are so hard to change...
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.
If not, why not? (Because I'd love to make it even better).
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."
If I had this thing I want, I could also use it as a debug console for servers...
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
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.
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.