4 ms·

> Third-party GUIs can be nice, but they generally provide very little value over a TUI What value does this messy method to reimplement GUI bring?

by eviks 3y ago

friend_and_foe 3y ago
You can run them remotely over SSH, for one. I also like the fact that it's hard to build a terminal application that needs a mouse. I don't want to touch a mouse if I can avoid it, so I run them. A personal computer is too powerful to operate with a single finger. There's the low resource aspect too. Sure, you can build a TUI that hogs resources, but there's a culture of not doing it, and it's harder to do it even if you try. Contrast that to modern GUI software where it's like the developers look at the minimum requirements as a speed limit, that is, the bare minimum you have to use.
- eviks 3y ago
  >A personal computer is too powerful to operate with a single finger. You might've forgotten due to no use, but mice don't use only 1 finger, and they don't prevent keyboard use either. The comparison to some general GUI state also doesn't make sense - that class of software is miles ahead of the TUI in terms of functionality, so you'd need to limit the comparison to apps that are functionally similar
  - friend_and_foe 3y ago
    I've found that with keyboard oriented interfaces the TUIs are as or more functional than GUI apps. And sure, having a mouse doesn't preclude you from using a keyboard, but GUI applications are so mouse focused it's impossible to use most of them without a mouse. The 1 finger comment was hyperbole, but it's close enough to true.
    - eviks 3y ago
      > it's close enough to true. I use various buttons and wheels and gestures and click sequences (LR switch tab left, RL switch tab right) and buttons-as-modifiers on a mouse, so not even remotely close The other point is repeating the same generalization mistake, "most of them" don't even exist in a TUI form, and the level of keyboard customization for keyboard focused interface is often pretty lackluster in a TUI (terminal text editors famous for their customization can't differentiate between left and right modifiers and it's harder to fix that with an external utility because, guess what, it's not a separate app, so usual app detection fails!)
cweagans 3y ago
If I was only running neovim, this wouldn't make much sense. However, I can use this method for any command line application. Since it's essentially just re-using my existing terminal, I can also re-use as much of my terminal emulator configuration as I'd like. I can also rely on the known performance characteristics of my terminal emulator. In particular, a number of the Neovim GUIs are energy hogs (either due to some unoptimized thing that uses a lot of CPU or the specific method that is used for rendering on the GPU). The other nice thing is that when I want to run Neovim, I start an app called Neovim. Not FNvim or Neovide or glrnvim or any of those other things. Neovim. It's a closer match to my intent and I don't have to try to remember some weird app name when I just want to edit code.
- eviks 3y ago
  > I can use this method for any command line application Which apps do you use actually it for? > when I want to run Neovim, I start an app called Neovim That's what aliases are for (or you could rename the binary?)! Or you could just bind it to shortcut+E for Edit and forget the name of the editor as you'd never type it The last trick could also solve the Cmd+Tab issue as you could set it up to open the in-terminal-editor, and it'll always be faster vs tabbing P.S. By the way, do you know the app https://github.com/sveinbjornt/Platypus https://github.com/sveinbjornt/Platypus that can generate app bundles on a Mac?
  - cweagans 3y ago
    > Which apps do you use actually it for? neovim, mutt, tig, weechat > That's what aliases are for (or you could rename the binary?)! Unfortunately, it's not that simple on macOS for app bundles. The human readable name of the app bundle really doesn't matter that much to the operating system -- it's the contents of Info.plist that matter. In order to have a separate app that can be Cmd+Tab'd to, you have to have a separate app bundle, separate app bundle identifier, etc. There's really not a way around it on macOS that I've seen. (And to be clear, aliases do work on the command line. I'm talking specifically about GUI apps - which is my primary method of separating my different activities. Terminal emulator tabs are not good enough.) This also doesn't solve the performance problems with any of the various GUI applications, nor does it solve my problem for other applications that I want to run. > By the way, do you know the app https://github.com/sveinbjornt/Platypus https://github.com/sveinbjornt/Platypus that can generate app bundles on a Mac? I do! I tried this route first, but it falls apart when you start a GUI application from the script that you supply to platypus. If your script is e.g. `wezterm start`, it'll just start up another instance of a wezterm-branded GUI app in addition to the wrapper app that Platypus spits out.
rollcat 3y ago
I've said it before and I will say it every chance I get: TUIs are poorly disguised GUIs, and the whole premise of TFA seems to be here to support this notion. If you want to integrate your TUI program more tightly with the terminal emulator it's running in, how about you rip out those half a dozen layers of abstraction and indirection and compatibility with half-a-century-old hardware that nobody produces anymore, that sit in between your program's display logic and the actual pixels on the screen? You can keep the grid-of-characters display style, but e.g.: - implement text selection that works in sub-frames - give your program an icon - support key combos like Ctrl+Shift+F - display an inline picture ...all while removing hundreds, probably thousands of lines of code.
- marcosdumay 3y ago
  TUIs have conventions that grant them high usability and accessibility. GUIs UI conventions never became that powerful, and new GUIs don't even follow most of the useful UI conventions. That's so generalized a problem that the newest GUI toolkits don't even have native support for a lot of the GUI conventions. That said, yes, without a doubt you can make a GUI that is as usable as a random TUI. You can even make it work well over ssh. And even get shorter code after it's done. You will just have a hard time communicating you did that to people.
  - rollcat 3y ago
    > GUIs UI conventions never became that powerful, and new GUIs don't even follow most of the useful UI conventions. That's so generalized a problem that the newest GUI toolkits don't even have native support for a lot of the GUI conventions. Yes, that's unfortunately the status quo. TUI's main saving graces, and the reason why it's actually a popular choice for modern apps, are: - It works everywhere (once you solve the portability quirks, which are present both at OS level and on each different terminal emulator) - The API is simple and stupid (paint a character here) - There's only this many things you can do, so you don't over-engineer your UI - Accessibility. Screen readers are guaranteed to work (but lack a11y context) I wish there was a simple and stupid, portable GUI framework that had all of these qualities, without the unnecessary historical baggage. htop or ranger are actually pretty good apps, just wish they weren't chained to an emulator.
xorcist 3y ago
Are you looking for an honest answer? Keyboard centricity, and the decreased usage latency that follows.
- eviks 3y ago
  What part of keyboard centricity is broken in a GUI NeoVim client? Also terminals vary significantly in input latency (though you might mean something else with "usage" latency), some higher than those of a GUI app https://www.lkhrs.com/blog/2022/07/terminal-latency/ https://www.lkhrs.com/blog/2022/07/terminal-latency/

> Third-party GUIs can be nice, but they generally provide very little value over a TUI What value does this messy method to reimplement GUI bring?

by eviks 3y ago

> Third-party GUIs can be nice, but they generally provide very little value over a TUI What value does this messy method to reimplement GUI bring?

friend_and_foe 3y ago

You can run them remotely over SSH, for one. I also like the fact that it's hard to build a terminal application that needs a mouse. I don't want to touch a mouse if I can avoid it, so I run them. A personal computer is too powerful to operate with a single finger. There's the low resource aspect too. Sure, you can build a TUI that hogs resources, but there's a culture of not doing it, and it's harder to do it even if you try. Contrast that to modern GUI software where it's like the developers look at the minimum requirements as a speed limit, that is, the bare minimum you have to use.

eviks 3y ago
>A personal computer is too powerful to operate with a single finger. You might've forgotten due to no use, but mice don't use only 1 finger, and they don't prevent keyboard use either. The comparison to some general GUI state also doesn't make sense - that class of software is miles ahead of the TUI in terms of functionality, so you'd need to limit the comparison to apps that are functionally similar
- friend_and_foe 3y ago
  I've found that with keyboard oriented interfaces the TUIs are as or more functional than GUI apps. And sure, having a mouse doesn't preclude you from using a keyboard, but GUI applications are so mouse focused it's impossible to use most of them without a mouse. The 1 finger comment was hyperbole, but it's close enough to true.
  - eviks 3y ago
    > it's close enough to true. I use various buttons and wheels and gestures and click sequences (LR switch tab left, RL switch tab right) and buttons-as-modifiers on a mouse, so not even remotely close The other point is repeating the same generalization mistake, "most of them" don't even exist in a TUI form, and the level of keyboard customization for keyboard focused interface is often pretty lackluster in a TUI (terminal text editors famous for their customization can't differentiate between left and right modifiers and it's harder to fix that with an external utility because, guess what, it's not a separate app, so usual app detection fails!)

cweagans 3y ago

If I was only running neovim, this wouldn't make much sense. However, I can use this method for any command line application. Since it's essentially just re-using my existing terminal, I can also re-use as much of my terminal emulator configuration as I'd like. I can also rely on the known performance characteristics of my terminal emulator. In particular, a number of the Neovim GUIs are energy hogs (either due to some unoptimized thing that uses a lot of CPU or the specific method that is used for rendering on the GPU). The other nice thing is that when I want to run Neovim, I start an app called Neovim. Not FNvim or Neovide or glrnvim or any of those other things. Neovim. It's a closer match to my intent and I don't have to try to remember some weird app name when I just want to edit code.

eviks 3y ago
> I can use this method for any command line application Which apps do you use actually it for? > when I want to run Neovim, I start an app called Neovim That's what aliases are for (or you could rename the binary?)! Or you could just bind it to shortcut+E for Edit and forget the name of the editor as you'd never type it The last trick could also solve the Cmd+Tab issue as you could set it up to open the in-terminal-editor, and it'll always be faster vs tabbing P.S. By the way, do you know the app https://github.com/sveinbjornt/Platypus https://github.com/sveinbjornt/Platypus that can generate app bundles on a Mac?
- cweagans 3y ago
  > Which apps do you use actually it for? neovim, mutt, tig, weechat > That's what aliases are for (or you could rename the binary?)! Unfortunately, it's not that simple on macOS for app bundles. The human readable name of the app bundle really doesn't matter that much to the operating system -- it's the contents of Info.plist that matter. In order to have a separate app that can be Cmd+Tab'd to, you have to have a separate app bundle, separate app bundle identifier, etc. There's really not a way around it on macOS that I've seen. (And to be clear, aliases do work on the command line. I'm talking specifically about GUI apps - which is my primary method of separating my different activities. Terminal emulator tabs are not good enough.) This also doesn't solve the performance problems with any of the various GUI applications, nor does it solve my problem for other applications that I want to run. > By the way, do you know the app https://github.com/sveinbjornt/Platypus https://github.com/sveinbjornt/Platypus that can generate app bundles on a Mac? I do! I tried this route first, but it falls apart when you start a GUI application from the script that you supply to platypus. If your script is e.g. `wezterm start`, it'll just start up another instance of a wezterm-branded GUI app in addition to the wrapper app that Platypus spits out.

rollcat 3y ago

I've said it before and I will say it every chance I get: TUIs are poorly disguised GUIs, and the whole premise of TFA seems to be here to support this notion. If you want to integrate your TUI program more tightly with the terminal emulator it's running in, how about you rip out those half a dozen layers of abstraction and indirection and compatibility with half-a-century-old hardware that nobody produces anymore, that sit in between your program's display logic and the actual pixels on the screen? You can keep the grid-of-characters display style, but e.g.: - implement text selection that works in sub-frames - give your program an icon - support key combos like Ctrl+Shift+F - display an inline picture ...all while removing hundreds, probably thousands of lines of code.

marcosdumay 3y ago
TUIs have conventions that grant them high usability and accessibility. GUIs UI conventions never became that powerful, and new GUIs don't even follow most of the useful UI conventions. That's so generalized a problem that the newest GUI toolkits don't even have native support for a lot of the GUI conventions. That said, yes, without a doubt you can make a GUI that is as usable as a random TUI. You can even make it work well over ssh. And even get shorter code after it's done. You will just have a hard time communicating you did that to people.
- rollcat 3y ago
  > GUIs UI conventions never became that powerful, and new GUIs don't even follow most of the useful UI conventions. That's so generalized a problem that the newest GUI toolkits don't even have native support for a lot of the GUI conventions. Yes, that's unfortunately the status quo. TUI's main saving graces, and the reason why it's actually a popular choice for modern apps, are: - It works everywhere (once you solve the portability quirks, which are present both at OS level and on each different terminal emulator) - The API is simple and stupid (paint a character here) - There's only this many things you can do, so you don't over-engineer your UI - Accessibility. Screen readers are guaranteed to work (but lack a11y context) I wish there was a simple and stupid, portable GUI framework that had all of these qualities, without the unnecessary historical baggage. htop or ranger are actually pretty good apps, just wish they weren't chained to an emulator.

xorcist 3y ago

Are you looking for an honest answer? Keyboard centricity, and the decreased usage latency that follows.

eviks 3y ago
What part of keyboard centricity is broken in a GUI NeoVim client? Also terminals vary significantly in input latency (though you might mean something else with "usage" latency), some higher than those of a GUI app https://www.lkhrs.com/blog/2022/07/terminal-latency/ https://www.lkhrs.com/blog/2022/07/terminal-latency/