24 ms·

> 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

by jolmg 20d ago

> 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 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.

ckardaris 20d ago
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.
- GreenWatermelon 15d ago
  OCR now comes built in with Spectacle, the default screenshot utility for KDE Plasma and it can copy the result right away.
- jolmg 20d ago
  OCR will always ultimately be guesswork. It's up to the font used whether 1/I/l/| or O/0 or -/‒/–/—/― can be differentiated.
orbital-decay 20d ago
>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.
- jolmg 19d ago
  > 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? Hold Alt while trying to select to make a rectangular/block selection. To avoid a TUI's mouse handling and use the terminal's, hold Shift. So, for example, if you're on tmux with "panes" (internal windows) side-by-side and you wish to copy lines from a middle one into your X11 primary selection, hold Alt+Shift+mouse1 and drag. Works on xterm and urxvt. I had hoped it worked on all terminals, but I notice it doesn't on kitty. Maybe there's an extension that adds support. Kind of a waste of opportunity to have a grid of monospaced characters and not be able to do rectangular selections. > 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. Yeah, the interfaces of coding agents are really poorly made. It's like they only know GUIs but wanted to have it work for a terminal. They really should have been CLIs instead of TUIs. That way you could just use the terminal scrollback buffer. Would've been simpler to implement, and they wouldn't have needed some special support for copying command and reply. > Most TUI apps suffer from terrible NIH and end up with their own homegrown incompatible keyboard navigation schemas you need to learn every time. Hmmm... not really? Maybe you're thinking vim vs emacs, but that's just because they're old and have separate histories. From the point they both became established on their own, multiple interfaces have supported their keybindings. Ranger for example supports vim keybindings for navigation. Something to remember is that GUIs don't have common ground on this except on the use of Tab and Shift-Tab for jumping between different parts of the interface. Also maybe Alt for invoking the menu bar. TUIs don't satisfy themselves with such terrible navigation. It's NIH and not-invented-anywhere. They must invent to be useful with keyboards. Mouse support comes second for TUIs. For GUIs, mouse support comes first and keyboards are an afterthought if they're ever thought about. It doesn't seem like GUIs have NIH-syndrome only because they either don't support keyboards or people aren't even familiar with the keyboard navigation they came up with since they only use the mouse.

by jolmg 20d ago

ckardaris 20d ago

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.

GreenWatermelon 15d ago
OCR now comes built in with Spectacle, the default screenshot utility for KDE Plasma and it can copy the result right away.
jolmg 20d ago
OCR will always ultimately be guesswork. It's up to the font used whether 1/I/l/| or O/0 or -/‒/–/—/― can be differentiated.

orbital-decay 20d ago

>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.

jolmg 19d ago
> 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? Hold Alt while trying to select to make a rectangular/block selection. To avoid a TUI's mouse handling and use the terminal's, hold Shift. So, for example, if you're on tmux with "panes" (internal windows) side-by-side and you wish to copy lines from a middle one into your X11 primary selection, hold Alt+Shift+mouse1 and drag. Works on xterm and urxvt. I had hoped it worked on all terminals, but I notice it doesn't on kitty. Maybe there's an extension that adds support. Kind of a waste of opportunity to have a grid of monospaced characters and not be able to do rectangular selections. > 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. Yeah, the interfaces of coding agents are really poorly made. It's like they only know GUIs but wanted to have it work for a terminal. They really should have been CLIs instead of TUIs. That way you could just use the terminal scrollback buffer. Would've been simpler to implement, and they wouldn't have needed some special support for copying command and reply. > Most TUI apps suffer from terrible NIH and end up with their own homegrown incompatible keyboard navigation schemas you need to learn every time. Hmmm... not really? Maybe you're thinking vim vs emacs, but that's just because they're old and have separate histories. From the point they both became established on their own, multiple interfaces have supported their keybindings. Ranger for example supports vim keybindings for navigation. Something to remember is that GUIs don't have common ground on this except on the use of Tab and Shift-Tab for jumping between different parts of the interface. Also maybe Alt for invoking the menu bar. TUIs don't satisfy themselves with such terrible navigation. It's NIH and not-invented-anywhere. They must invent to be useful with keyboards. Mouse support comes second for TUIs. For GUIs, mouse support comes first and keyboards are an afterthought if they're ever thought about. It doesn't seem like GUIs have NIH-syndrome only because they either don't support keyboards or people aren't even familiar with the keyboard navigation they came up with since they only use the mouse.