To their credit, they did donate a lot of VAX equipment to New Hampshire public schools where I grew up. They did seem to get the long game there. It certainly worked on me. DEC's bigger misses came later.
Very common for server software, where you may not have a GUI environment installed.
You can run SSH as a server on windows boxes easily now, and depending on your needs (or to standardize across a heterogeneous fleet of servers) it might make sense to have some good CLI/TUI utilities available that are cross-platform.
While I imagine most people won't jump to a TUI for Windows, it could also be a secondary interface for an application that's run on both Windows and Linux/BSD. If no GUI (or no Windows GUI) is detected, approximate the same display using a TUI. The guys of the application can be the same, and you don't have to ship two versions (assuming the rest of the internals area already portable).
Even on very high end machines, even when I'm running other GUIs, I still do a lot of stuff in the shell especially with regards to working on ssh'd machines.
It's really useful to have things work in the shell directly.
I live in Emacs. It is a program specialized for typing, displaying and navigating text. If whatever I need to do does interaction via text and typing all else is just fluff. Pointing and clicking is just a digression from what I want and what I need to do.
I am not even an old fart. I am barely 30, but I feel completely backwards with regards to all developments in modern computer interaction. I hate smartphones. I hate the modern web. It all feels like one big distraction.
Speed. They usually launch fast and are responsive, because there are no graphical resources that need to load or complex widget hierarchies that need to be constructed. There's no need to switch windows, because the TUI launches in the same window you typed the command into. You don't have to take your fingers off the keyboard because having a mouse is not expected in a TUI.
In principle, all of these things could be done with a GUI, but in practice, they're not, and with the phoneification of software, the keyboard is an afterthought, not the main input mechanism.
What I like about this in contrast to Miguel's TUI is how easy it is to change the colors for the interface.
I wish it would have mouse support, though - not sure how much effort it would be to add it to it. Mouse support is something I really like about GUI.cs
I've used WPF, and I have no specific issue with it (and believe it was an upgrade over Forms). But even as someone very familiar with C#/WPF, and a fan of C#/.Net Core I cannot see why you'd want to port WPF when a platform like Electron exists and already works extremely well as a cross-platform framework.
It isn't simply the functionality, but also the massive community/examples/tutorials/etc that already exist for the JavaScript/Node/Electron ecosystem. WPF, even on Windows, is much smaller but if they ever ported it to Linux/MacOS/iOS/iPadOS/Android the resources would be microscopic, and it would be a legitimate limiter to the platform's success.
It would largely be dead on arrival. I wouldn't even use it (and I am their core developer demographic). The only argument people can make is performance, and WPF isn't exactly speedy itself (particularly without hardware acceleration). Plus you're competing with a much better ingrained Qt.
I was actually trying to create a cross-platform solution this weekend between PyQt and Electron, and ultimately wound up using Electron, not because it is better within itself but because you have this huge ecosystem of samples/snippets/etc to built upon. It is a productivity multiplier.
There are many reasons why one would not want to use Electron to write an application.
- An Electron application is necessarily slower and larger than a native application with the same functionality
- An Electron application is yet another browser instance on a user's machine, with all the vulnerabilities of that version of Chrome
Those two alone are enough reasons for a lot of (but still far too few) developers.
Software is getting slower much more rapidly than hardware is getting faster, and one of the reasons for that is Electron and how seductive it is to application developers.
I can't really explain why, but looking at Avalonia's demonstration videos I don't like the UI controls in Avalonia.Themes.Default. They remind me of what you might end up with if you designed controls manually in e.g. a Flash app - it doesn't feel like a desktop app UI kit.
It's a bit of a shame, because I strongly suspect the theme is easily overridden. It just needs a designer to make a consistent set of controls.
The themes can be easily overridden indeed. Here [0] is example of custom theme applied. For sure the project would really benefit from some pro designer help.
I've seen this TUI term come up a few times on Hacker News. The term I've heard at two companies that had extensive terminal interfaces with menus and screens is CHUI (rhymes with "chewy").
It's funny, though: the CHUIs that remain in the product for system administration are much more primitive now than they used to be. Instead of curses-style graphics with a UI, it's pure text.
Very cool, can't wait to try it out! I've been using Miguel de Icaza's Console project with success but I feel this project might have a ton more options and flexibility!
This is very interesting. Really glad to see this implemented as a .NET Standard 2.0 package. I've had a huge problem with making UIs for various systems. Something like this could be a good starting point for building a cross-platform, minimally viable GUI for those systems. I don't need native-looking GUI, I just need functional and not completely broken like Unity's GUI system is/are.
Turbo Vision is still kinda sorta alive as FreeVision, shipped as part of FreePascal, and driving their TUI IDE that's visually a clone of Borland Pascal for DOS:
I was just thinking yesterday that it would be cool if there was something like this for VSCode, just like for the well known text editors, so I can launch it in an ssh session.
VS Code has really good support for editing over SSH built into a preview extension now [0]. It is as seamless as running vim over ssh, except it’s a GUI app running locally connected to a temporary VS Code server on the remote. It even supports extensions installed on the remote. I’ve tried so many different implementations to get Sublime working in this config (like SSH forwarding a samba share) and they’re all terrible compared to VS Code’s.
I use these kind of text based ui's for internal tools where dealing with a full graphical UI is often 50% or more of the actual work. It's easier for the novice user to use tools with basic text based user interface than to use command lines, but it's much faster to develop than a WPF app (and it's multi platform)
I think that this project is about displaying information graphically in a textual interface. I think with emacs you can do so but it's difficult. I think hydras are not this. Hydras are more or less for grouping commands together.
The example is .NET Core 2.1, but the actual library itself is .NET Standard 2.0.
It will depend on how the System.Console class is implemented in Linux and macOS. It might fair better to port the example to Mono or .NET Core 3.0 (which should just be a change of build settings).
https://en.wikipedia.org/wiki/Text-based_user_interface