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.
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.
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.
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.
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.
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?
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.
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 :)
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.
malkia|3 years ago
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.
WorldMaker|3 years ago
hdjjhhvvhga|3 years ago
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.
sebastianconcpt|3 years ago
hazrmard|3 years ago
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.
malkia|3 years ago
babypuncher|3 years ago
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.
tecleandor|3 years ago
xupybd|3 years ago
int_19h|3 years ago
jabart|3 years ago
VikingCoder|3 years ago
https://www.reddit.com/r/nextfuckinglevel/comments/xa50x1/ma...
Mountain_Skies|3 years ago
myth2018|3 years ago
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...
cheriot|3 years ago
malkia|3 years ago
bayesianbot|3 years ago
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.
VikingCoder|3 years ago
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?
cek|3 years ago
We're working on it [1]
[1] https://github.com/Blazor-Console/HACC/blob/main/README.md
sceptically|3 years ago
issung|3 years ago
zozbot234|3 years ago
mastax|3 years ago
_the_inflator|3 years ago
lostmsu|3 years ago
raphinou|3 years ago
colanderman|3 years ago
gwbas1c|3 years ago
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.
cek|3 years ago
https://github.com/Blazor-Console/HACC/blob/main/README.md
VikingCoder|3 years ago
I'd like to write MUDs (Multi-User Dungeon games) in C#...
mu_killnine|3 years ago
Way to go, team.
kgwxd|3 years ago
cek|3 years ago
Graphical.
Duh.
gulabjamuns|3 years ago
ripley12|3 years ago
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.
cek|3 years ago
amelius|3 years ago
cek|3 years ago
ape4|3 years ago
zamadatix|3 years ago
rod_ochoa|3 years ago
unknown|3 years ago
[deleted]
mavu|3 years ago
Very funny.
benbristow|3 years ago
If you haven't looked at .NET in a few years, you'd be surprised.
jeremycarter|3 years ago
daigoba66|3 years ago
bongobingo1|3 years ago
hulitu|3 years ago