I don't think the two use cases are mutually exclusive. You can have that keyboard driven muscle-memory workflow, while keeping things discoverable for users who haven't committed everything to memory.

Do you have examples where this is the case? In my experience, they've always seemed mutually exclusive.

the TUI library for tcell has mouse support, though you see it more in tview (or one of the dozens of maintained forks)

I've already experimented with dropdown menus and minimizing sections. While I too love the TUI and keyboard driven experience, many want something they can click on, less overhead from every application having their own hotkeys. For me, it's about reaching more people, and the hope that I can bring more of them into the mouseless development experience

> many want something they can click on [...] it's about reaching more people

To me, these reasons underscore the need for a genuine GUI, rather than a TUI that requires users to open a terminal just to have something clickable.

yeah, I've consigned myself to needing a GUI, but for the time being, iteration with a TUI is much faster. Our focus is also CUE, where working from the Go API unlocks way more possibilities. We get to keep the extra complexity of representing CUE constructs as JSON for sending on the wire. Though that GUI might be native and avoid all the web stuff anyway.

Many TUI programs, e.g. Midnight Commander, can use mouse, but are perfectly operable with just a keyboard. Same with Emacs or Vim in terminal mode.

This is more about blending in among GUI tools, which is also important.

> This is more about blending in among GUI tools, which is also important.

This is what I find difficult to understand, why is that important? And to whom?

It made sense 35 years ago when MS-DOS was shipped by default and you just had to make do.

Right now on my desktop I see 4 TUI windows, and 11 GUI windows.

A full-featured web browser or a video chat client can't be realistically made TUI. I could have run Emacs in TUI mode, but I appreciate variable font support in non-code texts I write.

For the videochat client it could be one video window with several panes (PIP, main+side small, ...) with a textual interface for controls, chatting etc.

Emacs?

zellij

Older versions of AutoCAD (though even the most recent can't escape the REPL) are a good example.

tmux. I know the keyboard shortcuts (that I customised) to create new windows and panes, and the shortcut to resize them all equally. I've not bothered to learn / remember the keyboard shortcuts to swap pane focus or resize individual panes because I've enabled mouse support and simply click where I want to focus and drag to resize.

they're really easy defaults. like modifier and arrow key.

AutoCAD is a great example of something that gives both options.

New users tend to get really involved with the buttons, but gradually shift to full text control over years.

Obviously in CAD sometimes you cannot enter coordinates and must grab the mouse... but it's still faster if you minimize use of the mouse.

I've found Fusion 360 to be highly mouse-driven with frustratingly few keyboard shortcuts available. It feels borderline unusable without having one hand on the mouse at all times to select various operations, and the faux-pie menus are too contextual to be a great replacement.

Tools like Plasticity CAD¹ or Blender feel way more keyboard-friendly in this space.

[1]: https://www.plasticity.xyz/

I think what you’re focusing on GUI’s that don’t target power users anymore while TUI’s that do.

Visual Studio (not Code), JetBrains, Photoshop, AutoCAD, Blender, every single tool for circuit simulation and FPGA programming would like a word with you.

Also lazygit and neovim (since you mentioned modals) are GUIs in the terminal. The entire reason for lazygit to exist is to have a user-friendly experience for people who don't want to use the more complex and spartian git cli.

> Visual Studio (not Code), JetBrains, Photoshop, AutoCAD, Blender, every single tool for circuit simulation and FPGA programming would like a word with you.

I am not sure why you think my comment is in disagreement of that.

> The entire reason for lazygit to exist is to have a user-friendly experience for people who don't want to use the more complex and spartian git cli.

Same, I fully agree with that statement.

From reading both of your comments it looks like you are saying that people who use [Visual Studio (not Code), JetBrains, Photoshop, AutoCAD, Blender, every single tool for circuit simulation and FPGA programming] fall into the category "general consumer" but people who use vim fall into the category "professional". That's not how I would distinguish professionals from general consumers.

Ah, I see, that's not what I meant (hence the 'TUIs are often tailored for advanced users' and 'the majority of GUIs prioritize user-friendly experiences for the general consumer' phrasing).

I agree there are also many GUIs tailored for professionals. Not sure if there are TUIs tailored for general consumers though.

GUIs have a rich history of power and complexity, which has been watered down over generations of business fucks insisting that everything be 'easy to use' so they can get those grandma dollars

Technically neovim is a GUI, but not in the sense most people would accept.

I"m a professional software developer and I like user-friendly experiences. I didn't know drop down menus and clickable buttons (thought that was the point of a button) are somehow anathema to advanced users

I typically use `<tab>-<enter>` on HN to click the button, advanced users will find a way... enter Vimium stage left

In theory GUI is a superset of TUI, there's nothing inherently bad or unproductive about GUI. You can argue in practice there exist a lot of unproductive GUI that's worse than a TUI client, but I think it's the problem of the designer, not the tool.

Also there are some areas that's universally acknowledged to be better suited for GUI, anything that requires visualization like video editing, image editing, 3d modeling, etc. Maybe someone can go full ffmpeg to edit a feature length film, but that'll take some effort.

> In theory GUI is a superset of TUI

Only if the TUI is non-scriptable. That's the big bait-and-switch possible here: Is it a TUI in that the menu system is made out of text, or is it a TUI in that it's a command line with a scripting language and the ability to create new commands out of composable pieces? Just saying "Textual User Interface" doesn't disambiguate the two.

How com GUI isn't scriptable? Most GUI is made from scripts. Or do you mean the ability for end user to extend the software with a software-provided scripting system. In that case that's not related to GUI and TUI, all application no matter GUI or TUI can be extended by scripts if the software author wants to support that.

I wish I could accurately share my experiences watching travel agents working on mainframe terminals finding me a good deal on flights in my travel windows.

it was amazing watching them work, and there was no mouse involved. there wasn't even a mouse connected to the terminal. F-keys and hotkeys galore, and the applications were extremely responsive, none of this 400ms response from a webserver then another 1200ms waiting for the JS to render the page.

I am in favor of TUIs if they can bring this kind of accommodation for power-users. I agree with you that there is a strong danger of UX people getting involved and making things perfect for new people at the expense of anyone advanced.

I've always thoght GUI designers/devs should have a Mouseless Friday (incl tochpad).

Some features are nice to have. Give dmenu [0] a try, pipe it into other CLI utils and see how useful it can be to have drop-downs sometimes.

[0] https://tools.suckless.org/dmenu/

I love dmenu and similar tools, also I don't consider dmenu to be a dropdown element as part of an application UI (like dropdowns are in GUI apps).