https://github.com/ironcalc/TironCalc
Into the main repo :
https://github.com/ironcalc/ironcalc
Now, I'm not 100% convinced ratatui is the way to go after seeing what the folks of Microsoft did with edit.
Anyhow, I think TironCalc is a great open source project to work with Rust and Ratatui.
ssh teletekst.nl
[1] https://tweakers.net/geek/237754/nos-maakt-teletekst-beschik...
I would guess I was doing something wrong, but it was really running an example from the official website. So I gave up on Ratatui.
The only places I know of is Awesome TUIs [0] and terminaltrove [1]
I can also see that Ratatui has an awesome list too [2].
[0] https://github.com/rothgar/awesome-tuis
Is anyone working on this?
With the speed terminals are and support for graphics through things like sixel and shaders I'd love to have a browser even if I couldn't do videos. Even if it was like viewing most pages in reader mode.
I'm not sure some big companies would be happy about that though since it likely would mean you could do things like ad blocking more easily. But maybe you could get them on board if you pitched it as a browser for LLMs. Something something it's a native interface for them. ;)
I know there's some browsers but things like W3M, Lynx, or *links* are... rough... definitely not of the quality we're seeing elsewhere in the current TUI revolution.
Rust is simply not meant for GUI-based data design but I still want Qt in Rust. That's it. Not QML or Slint. No markup at all. None of the immediate mode things. No other languages. Definitely not GTK. I'm worried it will never happen for Rust and it will be such a missed opportunity.
https://github.com/benjajaja/mdfried/
Markdown is really cool in the sense that you can still look at the raw text and read it easily. But one thing that always made me load up .md files in the browser was that it's just much easier to read when the headers are bigger.
So I wrote a markdown viewer that renders the headers as images. You need to configure your font once for it to work, can't really detect the terminal font. It obviously also renders inline images, which was another reason to use the browser.
And then, Kitty developed the novelty https://sw.kovidgoyal.net/kitty/text-sizing-protocol (I think it's now also implemented in Ghostty), which means we can skip the text-to-image processing and directly leverage that protocol.
Bluetui β A TUI for managing Bluetooth on Linux
https://news.ycombinator.com/item?id=45817114 https://github.com/pythops/bluetui
Any recommendations for something thatβs ergonomic to use and looks nice?
Thereβs a very real chance I just missed some initialization code that Ratatui might do out of the box that the other library was not.
Edit: Issues experienced by windows users were no colors, terminal flashing on every keypress, all keypresses registered as double.
Edit2: This miniature rant inspired me to go back to the commit and submit a patch to eliminate the event reporting on KeyUp and enable terminal colors.
Need to dust off my Turbo Vision and Clipper projects.
I find these apps so increadibly useful, I almost want to learn Rust :D
We just donβt have good desktop GUI platforms anymore. Qt and GTK are massive beasts, Windows changes theirs every 4 years (and no one wants to be tied to a single platform anyway), we donβt want to deal with Electron, and writing your own GUI from scratch is hard.
Terminals just got good lately and itβs way easier to make something higher quality in them than as a GUI. Itβs just too hard to make a good small desktop app.
Itβs the same reason why itβs easier to make something look great with LEGO than if you want to mold clay. Iβd also wager that devs today on average know more about good UX than devs did back in the 80s when clunky terminal apps used to be made.
My reference in this are Delphi .dfm files, which you rarely have to edit manually because they're handled by the IDE form builder. It is still a fantastic IDE to build native UI apps and I don't see a reason why Rust couldn't be used the same way.
A few reasons:
- for the most part TUI apps are cross-platform: macOS, Linux, BSD, Windows
- they cut down on context switching. If you're already in the terminal, you shouldn't have to switch to a GUI app to check on something.
- Today's terminal emulatorsβGhostty, WezTerm, Kitty, iTerm, Alacrity, etc.βare fast and capable with GPU acceleration, 24-bit color support running on high resolution displays. It makes for a compelling platform to code for.
- Anecdotally lots of developers are spending less time in IDEs and more time in the terminal using Claude Code, Gemini CLI, Codex, etc.
For me, often, itβs an escape for a GUI world taken over by out-of-control βdesignβ tenets. I value good Ux design concerns, but often working with designers lately feels bureaucratic, at times cargo culting, and overly spacious.
Itβs like a graphical form of βI didnβt have time to give you a short answer, so I gave you a long one insteadβ. TUIs force a paucity that often makes for a nice information/pixels ratio.
When Rust came along and presented a career opportunity, terminal apps was a great way to get into it and filled a gap in a lot of people's skill sets. Even when building GUI apps in Rust, your first entry point is a CLI usually.
We took our UX thinking from web & mobile and remixed it with Rust and new ideas came out. Turns out "If it aint broke don't fix it" for two decades can build up a lot of evolutionary pressure.
Submitters, please remember this from the guidelines:
... please use the original title, unless it is misleading or linkbait; don't editorialize.
It's glorious
https://sr.ht/~ireas/cursive-markup-rs/
the whole cursive library strikes me as very html-like in layout
Meanwhile, distributions sometimes maintain their plodding rate at package updates (usually handled by distribution volunteers, not the original program's developers), which was developed in an era when building from source was a tedious process where the distribution volunteers provided value.
In effect, build-from-source has taken over "just use the distribution package".
I see that there are some related discussions on the github: https://github.com/ratatui/ratatui/discussions/1927. Not sure if there is a solution though.
[0] https://github.com/NimbleMarkets/ntcharts/blob/main/examples...
Charm would probably say the same for Go.
You can already do this, since the 90s: Lynx[1] and w3m[2] have both existed for more than three decades at this point.
Absolutely fantastic description right there.
BTW, the video at the top of the repo readme won't open on any device I own.
"I like the A tool in category B. System C doesn't have tool A; system C is dreadful in category B".
I think you could have made the acute part of this argument about GUIs in rust 3 years ago, but not today!
I need to try Slint and GPGUI. I love EGUI, but need to do a proper comparison; could be missing out. This seems to be a concern of a different nature from the one you describe!
It's no less or more equipped than C or C++, so not really sure what to make of this comment given the username lol.
Not in the real world, where most of the useful software is not in fact written in Rust, nor Go for that matter.
And in the Unix world, build from source can be pretty easy. When itβs hard, itβs usually the projectβs fault (Firefox, Electron,..).
Theyβre very nontechnical.
Edit: A comment here linked to https://www.brow.sh/ It looks amazing.
I mentioned those by name...
>> I know there's some browsers but things like W3M, Lynx, or *links* are... rough...If you're willing to live in elisp, Emacs is amazing. I'm not, I'm always going to want to do it with ruby, and well, Emacs doesn't let you do that.
I am building tooling around "Verifiable Credentials" (the W3C standard, OpenID standard, and all the standards around and below it).
So me and my co-workers need tools to check JWTs, resolve DIDs, generate Proof of Possession, .well-known contents and services discovery, do OpenId Connect flows, interpret "offer requests", "presentation requests", QR-codes, etc. It started as a bucket of random commandline things that random devs whipped up when needed (in typescript, python, bash, rust, some PHP), and now slowly consolidated into a consistent "toolkit". I am currently still porting most of these tools to Rust and make their CLI interface and IO consistent.
But from there I'll be adding a TUI very quickly.
By no means meant as "end-user" software - those exist and called "wallets". But for developers and devops working in this niche. These don't need a GUI. I'd even wager these users don't want a GUI but prefer a TUI, but in any case, the TUI is just so much easier and more accessible for me as a dev that it's the choice between a TUI+CLI or no UI, just CLI.
I think writing a useful GUI has considerable overhead no matter which technology you use. In addition they cause other difficulties, like testability, i18n, l10n and accessability.
This is why people often resort to command line tools, rightfully so. There are cases, however, where a CLI won't cut it and I believe TUI's are a nice and lean solution that sits right between CLI and full-blown GUI and isn't going anywhere.
I have to agree with this, but for a lot of different things other than GUI as well. My friends all want me to use Rust, but I moved back to C++ after trying to do a lot of different projects in it after finding every crate I needed to be a WIP or abandoned state. There are the massive crates that are super popular of course, but it seems that once you get off the popular beaten path the available crates becomes far worse than any other language I have ever used.
Of course comparing Rust to something like Python or C++ is unfair to Rust, since Rust has had less time to develop those packages, but I think its more about the community at this point. I just don't see any enthusiasm for working on crates/frameworks. Most of the time when I find a crate I need, its sitting at version 0.3.0, last updated 1-3 years ago, with the documentation simply stating "Reimplementation of X in Rust, go read X's C++ documentation on how to use."
SSH apps serve a similar UX to web apps which I just think is a great idea for many use cases. Needing to install a cli tool just to upload some files is tedious when you can just use rsync, sftp, piping, or even sshfs
> but why would you render to a low-resolution 2D buffer with random character-hacks
Have you used a terminal in the last 5 years? We got graphics and everything now[0] > huge amount of overhead
A... terminal... with... large overhead? Surely you're joking. Have you met any gui app? Microsoft word takes a few gigs. Have you seen electron apps like Spotify or slack? My fucking mail client takes over half a gig and neomutt takes almost nothing.Either you're making numbers up or we live in different realities
> actual hardware acceleration?
Hardware acceleration has existed for years...Maybe stop making assumptions and check out what terminals can do. They've come a long way since the 80's. I'd suggest starting with something like ghostty.
Every GUI I replace with a TUI is one less flow-breaking obstacle where I have to suddenly reach for the mouse.
I starred Posting[1] but haven't yet got around to trying it.
[1]: https://news.ycombinator.com/item?id=40926211
Edit: here's another one: https://github.com/LucasPickering/slumber
I find egui far easier than Ratatui.
https://github.com/zed-industries/zed/tree/main/crates/gpui
See the discussion on a collection of elements ontop
There's no standard to communicate TUI semantics to assistive technology, and whatever few standards actually exist (like using the cursor to navigate menus instead of some custom highlight) aren't followed.
With GUIs, those standards exist, and are at least somewhat implemented by all major (non-Rust)UI frameworks.
Most TUIs donβt have these either. So I donβt see this as a difference between TUI/GUI. If you want to make a GUI and want to ignore these things, you are free to do so.
GUI is kind of unique because it's a really hard problem - both a ton of work and also a bit awkward to make ergonomic in Rust.
> last updated 1-3 years ago
That's way too low a bar. I bet most of these niche C libraries that don't have Rust equivalents are similarly slow-moving.
GNU Make regularly goes 4 years without a release but it's still alive.
Which is great, Zed's stack is pretty damn good. But like anything not yet widely used outside of its original use case, it can be rough around the edges, and just plain doesn't support anything that is not needed by Zed.
The good thing is that the image renderer definitely works on ghostty!
// Vidrun, born of the sea-wind through the spruce
// Vidrun, green-tinged offshoot of my bough, joy and burden of my life
// Vidrun, fierce and clever, may our clanΓ’β¬β’s wisdom be yours:
//
// Never read Hacker News
// - Aphyr, "Hexing the technical interview"
if (document.referrer.startsWith("https://news.ycombinator.com")) {
document.location = "https://upload.wikimedia.org/wikipedia/commons/d/d4/Human_fart.wav"
}
> https://www.boringcactus.com/assets/site.js cargo install ripgrep
which will result in ripgrep being downloaded, compiled, and copied to a per user directory that's included on PATH as part of the toolchain.EDIT: Which is what I'm doing right now for a few of these that caught my eye.
This is enormously better for UI response time and things like compressed files: you only transfer the compressed text, image, audio, or video files rather than the decoded form which can be an order of magnitude larger.
I sincerely hope it isn't the reason though, I'm a huge rust fan myself (10years of coding with it already) and I think rust is definitely the future, but that doesn't mean all previous open source foundations should be thrown away.
1. Consistent font and sizing. Pick the font you find easiest to read and set it in the terminal, now all TUI apps use it at the correct size.
2. Consistent theming. TUI apps use the same color scheme as your terminal, as your vim, etc. A consistent "desktop" is less distracting. Especially when you don't have to deal with crappy Electron apps displaying animations and ads (looking at you Discord).
3. Efficient on screen real-estate. Most TUI apps don't waste a lot of space on "padding", "giving elements space to breathe" or other "correct UX patterns". They tile nicely.
4. Never and issues copy and pasting. I used a GUI chat app recently that wouldn't let me select text, seriously.
5. Did I mention they are fun to use and relatively easy to develop?
Atuin replaces your existing shell history with a SQLite database, and records additional context for your commands.

This is a CLI utility for displaying current network utilization by process, connection and remote IP/hostname

Perform binary analysis in your terminal.

A customizable cross-platform graphical process/system monitor for the terminal

Codex is a terminal-native coding agent that can generate, edit, and run applications directly from your shell.

Play crossword puzzles in your terminal.
csvlens is A command line CSV file viewer. It is like less but made for CSV.

dua is a disk space analysis tool designed for speed, leveraging parallel processing to quickly provide detailed disk usage information and allowing for faster deletion of unnecessary data compared to the standard βrmβ command.
A command line tool that executes make target using fuzzy finder with preview window

TUI for git written in rust

gpg-tui is a Terminal User Interface for GnuPG.

Ranger-like terminal file manager written in Rust

A material design color palette for the terminal.

Markdown viewer for the terminal that renders headers as Bigger Text than the rest.

A mine sweeping game written in Rust

Oatmeal is a terminal UI chat application that speaks with LLMs, complete with slash commands and fancy chat bubbles. It features agnostic backends to allow switching between the powerhouse of ChatGPT, or keeping things private with Ollama. While Oatmeal works great as a stand alone terminal application, it works even better paired with an editor like Neovim!
oha is a tiny program that sends some load to a web application and show realtime tui

A simple TUI to view & control docker containers

Unlock the power of APIs with simplicity and speed, right from your terminal. View OpenAPI documentations in your terminal.

A lightweight and terminal-based tool for interacting with databases.

An application to manage markdown notes from your terminal and compile them to HTML

A simple oscilloscope/vectorscope/spectroscope for your terminal
Terminal HTTP/REST client

A CLI-based AI coding agent for local dev, scripts/CI, and automation.

A terminal user interface for taskwarrior

Television is a fast and versatile fuzzy finder TUI.
It lets you quickly search through any kind of data source (files, git repositories, environment variables, docker images, you name it) using a fuzzy matching algorithm and is designed to be easily extensible.
A network diagnostic tool that combines the functionality of traceroute and ping and is designed to assist with the analysis of networking issues.

A hackable, minimal, fast TUI file explorer
Blazing fast terminal file manager written in Rust, based on async I/O
Your browser does not support the video tag.
YΕzefu is an interactive TUI application for exploring data of a Kafka cluster.
It is an alternative tool to AKHQ, Redpanda Console, or the Kafka plugin for JetBrains IDEs. It includes a search query language inspired by SQL, providing fine-grained filtering capabilities.

An old school DOS TUI reads keyboard input one character at a time from a buffer, doesn't clear the buffer in between screens, and is ideally laid out such that a good part of the input is guaranteed to be fixed for a given operation. They also were built without mouse usage.
So an operator can hammer out a sequence like "ArrowDown, ArrowDown, ENTER, Y, ENTER, John Smith, ENTER" and even if the system is too slow to keep up with the input, it still works perfectly.
Modern GUIs almost never make this work near as well. You need to reach for the mouse, input during delays gets lost, the UI may not be perfectly predictable, sometimes the UI may even shift around while things are loading. Then also neither does Linux, I find that the user experience on DOS was far better than with ncurses apps that have all kinds of weirdness.
> Inspired by the gaming world, we realized that the only way to achieve the performance we needed was to build our own UI framework: GPUI. [0]
GPUI is not widely used because they only recently started publishing in crates.io [1] and still AFAIK their documentation is not that great yet, I suppose people will start using soon enough it, I was thinking on using it over Iced that was the other GUI that I feel that have future (because it's used by Cosmic Desktop).
[0] https://zed.dev/blog/videogame [1] https://crates.io/crates/gpui/versions
And copy / paste, "hm does this TUI intercept mouse clicks, ah it does, oh what was the key combo for my terminal emulator that allows to skip that? Crap I pressed ctrl-c instead of ctrl-shift-c". Or worse when you want to select text in a column-based TUI and your terminal emulator doesn't have any sort of column-selection handling.
With the path they've chosen, it may mean less version churn, but the other side is you've gotta wait for each widget author to upgrade their widgets when Ratatui upgrades. This can lead to a situation where some widgets upgrade, some don't, and you're left either on the lower version with unpatched issues, or the newer version missing widgets.
I much prefer the design of web-sys and js-sys, where all the features are included and gated behind feature flags.
Buttons are a good example. If you want to define a button theme, you have to individually define the theme for every possible state the button can be in. No inheritance, the best you can do is copy and paste them over (which means if you want to tweak one, you have to tweak them all). Compared to something like CSS, its a nightmare to theme even slightly interactive Godot GUI's
I'm betting on Slint. I kind of hated QML but it looks like they have learned a lot of lessons.
A fun example of this is https://www.terminal.shop/
I'm also not sure why you think it's an extra layer between the gpu. Both the browser and terminal emulator are sitting in top of the OS. But also remember if you run headless then your OS doesn't need to load the desktop environment, though you can still use the CLI. At this point clearly the GPU is seeing less, right?
TUIs have to be navigable by keyboard. They could be garbage in every other way, but at least they have that.
GUIs might have keybindings as polish if the developers put in the effort. Otherwise they either don't have keybindings, or they rely on generalized keybindings that come with the OS/UI toolkit that can be bad/impossible in arbitrary ways, like if tab is swallowed by an input so you can't even tab past a component or dismiss a modal. Or the only GUI is inside a web browser.
By default, TUIs have bad discoverability unless the developer puts in the effort. But at least you have keyboard navigation and run in a terminal.
By default, GUIs have bad keybindings unless the developer puts in the effort. In the worst case they aren't even kb navigable. But at least they tend to be discoverable.
We're fixing that in Ratatui 0.30 by introducing a stable core crate.
Another homegrown personal tool I had once written was in Go with DearImgui, so basically with AllenDang/giu... also really quite rapid dev and lean-enough binary / perf.
But Godot is wysiwyg for GUI stuff, so that's a plus..
I really want to love gpui and would like to avoid using webviews, the advantage of web-based apps is that accessibility is (relatively) easy to do if youβre attentive to it. At the time I looked at it, gpui did not support screen readers etc at all.
I suppose I understand why they made that decision given their business priorities, but itβs hard for me to tell my vision-impaired friends and colleagues that thereβs literally no way for them to use my app.
Whatβs actually hard with screen readers isnβt getting text (thatβs been easy on most GUI systems for decades) but communicating things in the right order, removing the need to see spatial relationships or color to understand whatβs going on.
TUIs make that harder for everything beyond mid-20th century-style prompt / response interfaces because you donβt want to have to reread the entire screen every time a character changes (and some changes like a clock updating might need to be ignored) so you want to present updates in a logical order and also need to come up with text alternatives to ASCII art. For example, if I made a tool which shows server response times graphically a screen reader user might not want to hear an update every second and if the most interesting thing was something like a histogram I might need to think about how to communicate the distribution which is better than rereading a chart every second only to say that the previous one has shifted to the left by one unit and a single new data point has been added.
Those are non-trivial problems in any case but theyβre all harder with a TUI because youβre starting with less convention and without the libraries which GUI interface developers have to communicate lots of context to a screen reader.
My logic with it being an additional layer is that instead of the browser rendering text to the screen, it would have to speak with the terminal for the terminal to instead render text to the screen. Same goes for rendering graphics. Besides a headless system I don't see much of a benefit to it.
> They could be garbage in every other way, but at least they have that
Not really, they could also not implement keyboard input for some interactions and only react to mouse. You could have a click-to-open-url in your terminal without a keyboard fallback setup. Of course, you could set it up, but that would be "polish if you put in the effort" There is no limit to garbage.
> Also once your workflow is increasingly keyboard based (like when using a tiled window manager),
Exactly, for example, you've set your Windows key to be reponsible for all window-based movements, so you have it move/resize app windows and want to have the same key help you move/resize "inner windows/panes/columns" in a TUI app. Well, tough luck, the terminal doesn't even recognize this modifier!
Again, "as polish if you put in the effort" you can achieve anything via some external remapping to supported keys, but "otherwise" you don't have keybindings, and don't even have generalized fallback common (though not universal, again, there is no limit to garbage) to GUIs.
Or you'd be unable to bind some key combo because in a terminal that key combo is equivalent to regular typing and you need to timeout to differentiate between the two, so a permanent friction.
> tab is swallowed by an input so you can't even tab past a component
Of course you can, use your keyboard to move the mouse pointer and click outside of the input field. All pure organic keyboard-based interaction! "They could be garbage", but at lest you have that keyboard-based option (yes, only "polish/put in effort")
2. specifically for "keyboard-centric tech users" that's a big fail since the terminal platform is not capable of supporting advanced keybindings presisely because all they do is "target the lowest common denominator" (as defined in 1965) of keybinding support!!! So your cool setup from a GUI code editor is simply not transferrable.
3. this is very rare, I mean, just look at the screenshots, a lot of them couldn't even add non-gapped borders=== ---!
There's no protocol that tells a screen reader to say something different than is actually displayed on the screen. The best you can do is having a whitelist of screen reader process names and changing how your TUI works if one of them is detected, but that's brittle and doesn't work over SSH. You'd also have to think about how to do container escaping and interfacing with the host system when you're running in WSL, as the screen reader is almost certainly on the host side.
> A website can be as intensive as Word.
Word has no business being as intensive as it is. It is a bloated piece of garbage.I love how Slint works on embedded devices too.
I'd probably put them in a third, discarded, mutant category where they are mouse-first applications that run in the terminal. Thus like GUIs, keyboard-support is bolted on.
So a better distinction here is mouse-first vs keyboard-first, but I think "TUI vs GUI" is close enough to that and it kinda stands in for that distinction in most cases.
Vim, tmux, and weechat would be examples of keyboard-first TUIs where mouse support is bolted on as polish, but never required.
Where you lose me is that every example you can think of where a bad TUI might not perfectly mesh into a keyboard-only workflow, the GUI counterparts to that example is much worse. So we would just agree that it's a bad TUI rather than anyone going "you're right, the average GUI is much better if keyboard-driven control is my priority".
I don't understand some of your examples though. Your super key is always at a global level that you wouldn't expect apps to read, that's the point. And using timeouts to handle keybinding collisions or something? Dunno what that looks like nor why you would do it. The examples are like if I said GUIs suck because it's a dreadful experience if you insist on using your mouse upside down.
While most gui ones also have hotkeys, most people only remember a tiny selection and have to rely on navigating menus and dialogs to access stuff they can't remember which makes their usage very slow.
2. Again, it's not about the possible capabilities. Objectively, GUI programs contain a superset of possible TUI programs (since your GUI program could be a terminal emulator). It's about it being a shibboleth: I can be pretty confident that the TUI application will have a keyboard-based workflow, and I can be pretty confident that the TUI application will be targeting a technical user base, because those are the only people building and using TUI tools. The "lowest common denominator" in that sentence was referring to the users not the systems.
C| Column Wide |
o| |
l||
1|2|
Egui is easy to get started with, and has a lot of widgets that work out of the box. The performance story isn't great, layout options is terrible (largely due to being immediate mode), and it is not very customizable. You take what they give you, and you like it.
Iced is a phenomenal and well-thought out API that is a wonder to work with. When it does what you need, which it often doesn't because it's not nearly as complete as the alternatives. But if you know that a monad is a monoid in the category of endofunctors, Iced might be right for you.
Slint is like Qt, but Rust. I don't think I need to say any more - if you have used Qt before, that sentence either immediately sold you on it, or convinced you to never go near it.
GPUI is a wonderful, extremely fast, stable, perfect API. If you are making a cross-platform native text editor. If you are doing anything else, sorry :(
There are a slew of projects bridging rust to run packaged browser apps which have some sort of DSL for specifying HTML front ends. People seem to like this for some reason. Some people also like being chained up in leather and whipped. I sometimes wonder if these are the same people.
Ratatui really is the best of the bunch. It has layout, accessibility, nice and easy user interface. It's a wonder to work with. Only problem: it is a TUI, not a GUI.
It's indeed a better distinction, but no, TUI vs GUI is nowhere close, specifically for your explicitly mentioned use case of "workflow is increasingly keyboard based" because that's exactly where GUI shines as it has much fewer fundamental limitations in keyboard handling.
> than anyone going "you're right, the average GUI
That's your strawman framing, why would I care about "the average"? It's not a limit for anyone, one can always choose a better-than-average app. My point is that at the top there is no comparison because TUIs offer nothing and have much bigger fundamental limitations. So of course with the wrong framing you can find worse examples.
> And using timeouts to handle keybinding collisions or something? Dunno what that looks like nor why you would do it.
Terminals send Esc for Alt-X combos, so to differentiate those combos from a single Escape press you need to track timers (if no extra key signal, then it's Esc, if another key signal, then it's a combo). And Esc is one of the most used keys in e.g. Vim
> Your super key is always at a global level that you wouldn't expect apps to read, that's the point.
Of course I would! What I wouldn't expect is for the app to override any global OS function bound to that key, but I would definitely expect to be able to not waste a whole thumb-conveniently located modifier just because
That's very close to my point - you're used to some trivial keyboard workflow, so wasting the whole modifier is just fine, you can't even comprehend why someone wouldn't want that, it's like a mouse upside down!
Menus are also not slow by any measure, they're only needed for discoverability, can be navigated with the keyboard as well, and aren't that different from the menus many TUI apps have (e.g. Midnight Commander). Moreover, there are real novel ideas like Microsoft's ribbon, which basically combine vi-style input and discoverability. Hotkeys is just one way to drive a GUI app using the keyboard, out of many.
2. but what's the value of a shibboleth if it's not reflected in capabilities??? Why would you care that a TUI app targets "tech user base" if you also know it will be less capable in your 'keyboard-centric' workflow due to platform limitations? And LCD for users just doesn't make sense, what user quality are you min-aggregating?
> This is absolutely not true for a GUI which could easily just be an opaque rendered canvas. Are you not aware of OCR? Besides, GUIs have special accessibility tools, which almost none of the TUIs have, so your opaque canvas isn't universal.
> The fact remains:
That's a myth, not a fact, and you fail to establish "the fact" even in the most basic example