Posted by ckardaris 14 hours ago
But the broader trend in GUI apps has been to target marketshare not deliver productivity for keyboard users. Back in the 80s and 90s Photoshop, Illustrator etc. became the powerhouses they are today because they focused on allowing professionals to be extremely efficient using their array of powerful keyboard shortcuts. In 2026 when software companies are dying of KPItis scoring their product management on creating compelling subscription models to hook customers, attention to actually delivering productivity for keyboard users is often an after thought. Mobile apps don't have keyboard shortcuts and desktop apps seem to increasingly be treated as as the narrow "edge case" with only a few hundred million target users versus the billions available on mobile devices. It's an opportunity for those who get serious about delivering value by leveraging the power of keyboard shortcuts to make their GUIs highly productive and comprehensively usable from the keyboard. For all their faults, Microsoft got this right with VSCode.
> But the broader trend in GUI apps has been to target marketshare not deliver productivity for keyboard users.
It's not a trend, it's a fallout of Electron being the default choice. Devs that use non-web UI frameworks are aware of keyboard navigation, or at least don't disrupt the builtin thing. And of course what devs that don't target power users tend to do is irrelevant to GUI vs TUI debate in the context of power users.
Instead they should be engineered in a way that allows users to bypass those developers in a (at least) framework-consistent way as there will never be a time when they collectively become "keyboard-wise".
For example a GTK app main context menu can be triggered with F10. But this relies on the developer to correctly "tag" said context menu.
In simple cases it is obvious what to do, but in more complicated designs, where you may be able to achieve the same visual output in different ways, it may not be so obvious.
In that case, it is up to the developer as well to read and try to follow the published guidelines.
(not that the tags shouldn't exist, they can make customization easier, just that they shouldn't be necessary for any framework menu components)
What complicated designs do you have in mind?
I would argue that any sufficiently powerful framework also provides more ways to diverge from the "proper way", so it puts more pressure on the developer to actually study and understand the framework design patterns.
- New *G*ame - *S*ettings - *Q*uit
Ideally keys should be centered around an area of the keyboard and not just the first letter.
Something to consider is a terminal that has keyboard navigation of its own. Through a terminal shortcut, I can move the cursor at will and copy any text at all, even if it's part of the interface of a TUI. If I want to copy the filepath of the file I'm working on in vim to then use in a shell, for example, it takes like 5 keys to copy it straight off vim's statusbar. A graphical text editor can display the filepath in a tab or something, but I can't copy the text off the tab.
I don't know if I'm alone in this, but it's very frustrating to want a piece text, see it in front of you, and you can't copy it because the developer for one reason or another didn't implement copying of that text, so you have to type it out even if it's right there.
Sometimes it seems on purpose too. For example, when a game on Steam gets updated terms of use, you get presented with a window showing the terms, but you can't copy them to save them. It's like the purpose is to just accept and forget the terms. A TUI can't prevent the user from copying text by its very nature.
Any terminal can implement this kind of arbitrary-text keyboard navigation on its own and have it work for all TUIs. Were e.g. GTK to implement something like this, it would only work for GTK apps, not for all GUI apps. This is exclusive of TUIs because TUIs are text-driven while GUIs are pixel-driven.
Funny but I struggle with copying anything in most recent TUIs. Fancy padding or multiplexer borders and multiple lines of text? It breaks. Incomplete text in a spreadsheet column (tabiew) or a narrow internal window? It breaks. Ohmypi literally has a separate command to copy the prompt because of that, and another command to copy the model reply. TUI is just a poor choice here, it doesn't play well with formatted text like markdown, UI controls, long text, and so on. Terminals are good for CLI where the text is presented as lines, not TUI with spaced layout.
>Any terminal can implement this kind of arbitrary-text keyboard navigation on its own and have it work for all TUIs. Were e.g. GTK to implement something like this, it would only work for GTK apps, not for all GUI apps. This is exclusive of TUIs because TUIs are text-driven while GUIs are pixel-driven.
Terminal navigation has nothing to do with TUI navigation. Most TUI apps suffer from terrible NIH and end up with their own homegrown incompatible keyboard navigation schemas you need to learn every time. Of course absolutely nothing prevents you from writing a TUI framework with a common schema, at which point you will be at the mercy of the dev using this or that framework and schema, same as with GTK and Qt. None of this is unique to TUIs or GUIs.
I wish this was a default, but also that there was more of a standard to navigate UIs. That's why I really like vimium and other similar extensions, it's following the vi logic across websites, rather than having to learn everyone's idea of how to navigate.
"It should be possible to move around and interact with every part of your user interface using the keyboard."
Yes, finally. It works both ways; when I have hold of the mouse, I don't want to reach for the keyboard, and vice versa. Windows has had this problem for ages, and probably always will. There are some workarounds, "ctrl-esc" (I do this all the time) and "windows-button", but some of them require really jumping through hoops.
One of my main issues with KDE is that the default keybindings for desktop operations feel like they were designed by people who don't navigate their desktop with a keyboard.
Then there are little things like in Gnome the screenshot implicitly copies to the clipboard, while in KDE you have to click the copy button. There are just little points of friction I experience in KDE that make me yearn for Gnome's workflow. I think my ideal world I would have a KDE desktop that used all the Gnome shortcuts, and worked more like Gnome.
It occurred to me that this is a wonderful way to design software: you immediately know the keyboard shortcuts because you’re already looking at them. I’m working on taking what I’ve built for the qwerty midi keyboard controller (which is built on hammerspoon) and making it just a generic interface for any kind of app.
If the end goal is navigating and controlling the app via keyboard shortcuts, so why not bake that into the design of the GUI itself?
My project if you’re curious: https://github.com/mattdanielmurphy/qwerty-midi-hammerspoon
I just prefer TUIs, I think if you prefer GUIs you should very much use them and ask for more of them, but if you prefer TUIs please do use those too. I could go into all the reasons I prefer TUIs but this is a HN comment not a manifesto.
Please just use and develop what you prefer.