GUIs should be fully keyboard-driven • Hacker News Board

Re: GUIs should be fully keyboard-driven

#101

Post by ckardaris » Fri, Aug 28, 2026, 6:18 PM UTC

jolmg wrote: post #59

> While it’s true that if you randomly pick a GUI and a TUI application, the latter is more probable to be fully keyboard-driven, this does not tip the scale in favor of developing TUIs over GUIs3. What it does is highlight the inadequacies of keyboard navigation in many GUI applications. Something to consider is a terminal that has keyboard navigation of its own. Through a terminal shortcut, I can move the cursor at…

Any text-centric action will have a great advantage when done inside a terminal. I would think the equivalent in GUIs would be first-class OCR support on the compositor level. I am not informed about any progress made in that region to be honest, so I cannot tell how close we are (or not) to this.

Re: GUIs should be fully keyboard-driven

#102

Post by connicpu » Fri, Aug 28, 2026, 6:18 PM UTC

YmiYugy wrote: post #88

What does it mean though for a GUI to be keyboard-driven? The obvious way is that every action simply gets a shortcut assigned. My counter would be that that is not really keyboard-driven, but merely keyboard-compatible.There is the issue of discoverability. The best practice right now seems to display the shortcuts of buttons in tooltips, menu items, or when pressing a different shortcut. I’d content that buttons ar…

One of the reasons I loved learning Helix is that it shows you the list of possible next keypresses every time you press the first key in a combo. Amazing for discoverability. It even works for user defined shortcuts!

Re: GUIs should be fully keyboard-driven

#103

Post by orbital-decay » Fri, Aug 28, 2026, 6:21 PM UTC

jolmg wrote: post #59

> While it’s true that if you randomly pick a GUI and a TUI application, the latter is more probable to be fully keyboard-driven, this does not tip the scale in favor of developing TUIs over GUIs3. What it does is highlight the inadequacies of keyboard navigation in many GUI applications. Something to consider is a terminal that has keyboard navigation of its own. Through a terminal shortcut, I can move the cursor at…

>A TUI can't prevent the user from copying text by its very nature.

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.

Re: GUIs should be fully keyboard-driven

#104

Post by 111nation » Fri, Aug 28, 2026, 6:22 PM UTC

gorjusborg wrote: post #96

I love TUIs. I move much faster when I don't have to take my hands off the keys to nudge the rat. However, I don't think my preference for TUIs is about my efficiency. The most important reason I love TUIs is that they generally only have a base set of features needed to get the job done. Most GUIs go off the rails, implementing features for use cases few people have. TUIs tend to be small, fast, and focus on a small…

Thats really true, small software thats easy to run, and launches instantly has a place in my heart as well. The get sh*t done centric workflow that TUIs offer is so unfortunately often lost in multiple layers of GUI controls...

Re: GUIs should be fully keyboard-driven

#105

Post by dietr1ch » Fri, Aug 28, 2026, 6:22 PM UTC

YmiYugy wrote: post #88

What does it mean though for a GUI to be keyboard-driven? The obvious way is that every action simply gets a shortcut assigned. My counter would be that that is not really keyboard-driven, but merely keyboard-compatible.There is the issue of discoverability. The best practice right now seems to display the shortcuts of buttons in tooltips, menu items, or when pressing a different shortcut. I’d content that buttons ar…

To me spacemacs nails the discoverability aspect through helm-Mx-fuzzy-matching and which-key

No clutter, but hints come as you stutter on what to press next

Re: GUIs should be fully keyboard-driven

#106

Post by chuckadams » Fri, Aug 28, 2026, 6:25 PM UTC

eldaisfish wrote: post #97

manlymuppet wrote: post #56

Power user experience is not the same thing as user experience in general. If you want to make the argument that all developer tooling should be keyboard-driven, fine, be my guest. But most people aren't willing to deal with the learning curve of keyboard-driven GUIs, and that's okay. We shouldn't force it. HN's insistence on acting like all users are Arch Linux efficiency perfectionist hacker types is painfully corn…

you are arguing against a strawman. Most reasonable people want support for both keyboard and mouse-based navigation. For example, why did Edge and possible chrome, remove support for Back via the backspace key? Literally, why remove something that exists and that some people might use? Same with some web forms where hitting enter in a text box does nothing. I expect it to submit a form, but very often, it does nothi…

> For example, why did Edge and possible chrome, remove support for Back via the backspace key?

Because people were triggering it by accident all the time. Firefox and Safari don't navigate back on backspace either.

Enter only auto-submits if there's a visible submit button or if there's just one input, and that behavior goes back as far as I can remember.

Re: GUIs should be fully keyboard-driven

#107

Post by ckardaris » Fri, Aug 28, 2026, 6:25 PM UTC

thibran wrote: post #95

Rygian wrote: post #79

Earlier quoted context omitted.

Top of my head: - Tab to move across fields. - Left-to-right, top-to-bottom focus. - Space to toggle togglable stuff. - Alt-Down Arrow to deploy drop-down stuff. - Arrows to move around. - Enter/Esc to accept/discard a modal. Or maybe I misunderstand the things you call "mouse things".

This does not work great. What if you have a grid of 30 item, do you press 20 times tab to focus finally the item you want to interact with? Keyboard design is much more, its also about how and where to place items, how things should move... it's a whole world. In the mouse world we have "discovered" those things and now we "just copy" other designs that we know work fine.

> What if you have a grid of 30 item, do you press 20 times tab to focus finally the item you want to interact with?

If this grid a central component of the application and navigation inside it is very common, I would argue that there should be a way to quickly move around the cells. The "how" is up to the specific application and the paradigms it promotes. For example, line navigation in vim is possible with "G", but such a shortcut would seem absurd in another application.

Re: GUIs should be fully keyboard-driven

#108

Post by emacdona » Fri, Aug 28, 2026, 6:25 PM UTC

OroPla wrote: post #67

marklar423 wrote: post #13

I agree but I think being usable by the keyboard isn't enough, because the shortcuts are often hard to discover and remember. I think the ideal is - like good TUIs - GUIs should put obvious hints on screen how to navigate via keyboard. It would be really great to have some GUI frameworks for the common platforms (including web!) designed to do this and have some opinions on common shortcuts for common actions so we c…

Agreed. Also, I would support everyone building off of vim principles. If keyboard bindings are somewhat consistent across applications, that would be really nice and there are already a bunch of options using vim bindings as a starting point, since they make intuitive sense once you've learned the "language" vim uses.

Yeah, keyboard binding consistency is what I really want. Ideally, you could choose between Vim, Emacs, keybindings for the program you're using.

I think what's also needed is a standard way of navigating what I guess I'll call the "focus tree". For example, if I'm running Vim inside of a terminal multiplexer (eg: Zellij) inside of a terminal emulator inside of a tiling window manager (eg: xmonad)...

It would be GREAT if I could use Vi keybindings to navigate windows in whatever "focus layer" I'm at... and then have a "standard" keybinding to navigate up and down that tree (eg: "Ctrl + >" and "Ctrl + Right now, everyone seems to solve the "focus tree" problem by trying to choose a control key combination that won't collide with any other process that might be listening for key chords at the same time.

Re: GUIs should be fully keyboard-driven

#109

Post by toast0 » Fri, Aug 28, 2026, 6:27 PM UTC

Telaneo wrote: post #91

oneeyedpigeon wrote: post #80

Earlier quoted context omitted.

Do you have an example of how supporting a keyboard shortcut for every action could be bad for a general audience?

Devil's advocate: showing the relevant keyboard shortcuts in the UI can be overwhelming (or at least one of many parts that all together become overwhelming) to new users, while not having them shown at all makes them undiscoverable. I think this is a bad reason. Even MS Office has made this work. But I've seen people act on this type of argument. If nothing else, it should be possible to have a settings menu where y…

> showing the relevant keyboard shortcuts in the UI can be overwhelming

Underlining the accelerator key is subtle and shouldn't be overwelming. Keyboard navigation unaware users probably won't even notice.

Re: GUIs should be fully keyboard-driven

#110

Post by Gecko4072 » Fri, Aug 28, 2026, 6:28 PM UTC

I've thought how i dislike both keyboard and mouse navigation from an ergonomics standpoint. Fine motor control for hours. I'd low-key want a neuralink beacuse speech is too awkward. Maybe mixed with eye monitoring.