4 ms·

The amount of these that are scriptable, that are automateable, is sadly sadly sadly low. This feels like such a dangerous new cargo cult to me: ooh terminal g

The amount of these that are scriptable, that are automateable, is sadly sadly sadly low. This feels like such a dangerous new cargo cult to me: ooh terminal good, hackers are here! Let's build applications for this! Ok, so... you may be in the console. But unless your program can be easily controlled & ran by other command line processes, unless it has machine-readable output, imo, you've simply imported the bad/ill/damaged/corrupt into a world that historically was usually much better. Building little isolated insular worlds is what apps do. On the terminal, I expect systems to compose & interoperate well. I have yet to see a TUI toolkit/library that demonstrates any form of commitment to first-principles of the shell world. That was my comment 26 days ago, seeing Bubbletea[1], a leading Go based library. This all feels so icky, so wronghearted to me. It could be done responsibly- yes- but it's not. This feels so wildly to be missing the point of the terminal, the shell: to be a complex, interwoven system, where anything- not just some basic pre-determined rote functionality- is possible. [1] https://news.ycombinator.com/item?id=30391605 https://news.ycombinator.com/item?id=30391605

betwixthewires 5y ago
Wouldn't it make the most sense to write a CLI application with an api, then a TUI wrapper that interfaces with it?
- rektide 5y ago
  I think there's a lot of possible paths we could down from here. Your path sounds like a totally viable suggestion that would definitely work! It's never quite been as easy/convenient as it should be, but services which offer a non-console but other machine-to-machine interface could suffice. Which if any of these listed examples offer HTTP or DBus interfaces for control? (Not a lot, alas, but perhaps some?) If you do want to build an application, these are good ways to make it externally controllable. I'm not aware of any dbus nor http tooling that makes interfacing with these protocols super slick & easy & friendly from the command line, but there's at least ways to do both, and we probably ought refine our script-foo in both realms. Another thought is that the libraries/frameworks could help a lot. Ultimately frameworks like Bubbletea are ways to display stuff & script actions. Why don't we make those actions first class citizens and have the library natively expose actions in a command line format? I dont a lot of console apps do this, but a pattern I love is being able to feed a command sequence into a console program. This example is terrible, I need to think of something more purposeful, but for imagineering sake, perhaps: my-tui-music-player --enqueue album:40-oz-to-freedom --enqueue album:steal-your-face --randomize --play 10 --wait 20s --volume 0.8 --clear-playlist --enqueue never-gonna-give-you-up --play --wait 20s --pause
  - zorr 5y ago
    To me it feels like there is distinction between cli binaries and TUI apps. They are both user interfaces, the former in a paradigm that allows composing in scripts and shell pipelines while TUIs provide a visual stateful UI. Both have their place. Often you'll see TUI apps being built on top of their cli counterparts, in other cases both interfaces are built on top of a common library. What you describe in your music player example is a cli interface and imho shouldn't be in the TUI binary.
  - mrlemke 5y ago
    TUIs are better for visual representation and interaction on resource constrained systems. Just keep using the CLI if that's what you want. I'm not sure why you need HTTP or dbus for control. Just use stdin and stdout. For example: cat << EOF | my-cli-music-player enqueue album:40-oz-to-freedom enqueue album:steal-your-face randomize play 10 wait 20s ... EOF This works with other CLI programs. For example (make sure you have dc and espeak): cat << EOF | dc | espeak 100 k 22 7 / p EOF
    - rektide 5y ago
      I need to validate but I expect many of these tools will not handle piped input properly, use event loops or otger tools that expect keyboard input as events not just streams. Other prosaic applicationisms abound- How does one send cursor up, or F10 to get into a memu, to an app via stdin? The paradigm falls appart, & TUI's as distonctly different elements than regular cli tools rears it's ugly head. Tools like espeak and dc that you cite fall into the conventional cli-tools camp. By compare mamy of the TUI tools we see here have their own autocomplete systems embedded in the program, multiple screens, full terminal layouts, multiple on-screen focus-able areas.
BeetleB 5y ago
Honest question: Do you have the same complaint about GUIs? As in, do you go to various Github pages for GUIs and make similar comments? Or is this expectation more for TUIs?
- rektide 5y ago
  I do think GUI programs should have machine-to-machine interfaces built in too, yes. I was young & barely knew it, but KDE's DCOP seemed like a very adequate way to script & control any app- that was awesome. Today on FreeDesktop, some apps do a good job of exposing themselves via DBus; music/media players in particular have very widespread support for the mpris interface, for example, but all sorts of apps expose control this way. The programming language Vala[1] in Gnome world has excellent DBus integration built in, so one can take some of their application models & expose them to the world, very much easing making m2m interfaces. [1] https://wiki.gnome.org/Projects/Vala/DBusServerSample#Type_Table https://wiki.gnome.org/Projects/Vala/DBusServerSample#Type_T...

betwixthewires 5y ago

Wouldn't it make the most sense to write a CLI application with an api, then a TUI wrapper that interfaces with it?

rektide 5y ago
I think there's a lot of possible paths we could down from here. Your path sounds like a totally viable suggestion that would definitely work! It's never quite been as easy/convenient as it should be, but services which offer a non-console but other machine-to-machine interface could suffice. Which if any of these listed examples offer HTTP or DBus interfaces for control? (Not a lot, alas, but perhaps some?) If you do want to build an application, these are good ways to make it externally controllable. I'm not aware of any dbus nor http tooling that makes interfacing with these protocols super slick & easy & friendly from the command line, but there's at least ways to do both, and we probably ought refine our script-foo in both realms. Another thought is that the libraries/frameworks could help a lot. Ultimately frameworks like Bubbletea are ways to display stuff & script actions. Why don't we make those actions first class citizens and have the library natively expose actions in a command line format? I dont a lot of console apps do this, but a pattern I love is being able to feed a command sequence into a console program. This example is terrible, I need to think of something more purposeful, but for imagineering sake, perhaps: my-tui-music-player --enqueue album:40-oz-to-freedom --enqueue album:steal-your-face --randomize --play 10 --wait 20s --volume 0.8 --clear-playlist --enqueue never-gonna-give-you-up --play --wait 20s --pause
- zorr 5y ago
  To me it feels like there is distinction between cli binaries and TUI apps. They are both user interfaces, the former in a paradigm that allows composing in scripts and shell pipelines while TUIs provide a visual stateful UI. Both have their place. Often you'll see TUI apps being built on top of their cli counterparts, in other cases both interfaces are built on top of a common library. What you describe in your music player example is a cli interface and imho shouldn't be in the TUI binary.
- mrlemke 5y ago
  TUIs are better for visual representation and interaction on resource constrained systems. Just keep using the CLI if that's what you want. I'm not sure why you need HTTP or dbus for control. Just use stdin and stdout. For example: cat << EOF | my-cli-music-player enqueue album:40-oz-to-freedom enqueue album:steal-your-face randomize play 10 wait 20s ... EOF This works with other CLI programs. For example (make sure you have dc and espeak): cat << EOF | dc | espeak 100 k 22 7 / p EOF
  - rektide 5y ago
    I need to validate but I expect many of these tools will not handle piped input properly, use event loops or otger tools that expect keyboard input as events not just streams. Other prosaic applicationisms abound- How does one send cursor up, or F10 to get into a memu, to an app via stdin? The paradigm falls appart, & TUI's as distonctly different elements than regular cli tools rears it's ugly head. Tools like espeak and dc that you cite fall into the conventional cli-tools camp. By compare mamy of the TUI tools we see here have their own autocomplete systems embedded in the program, multiple screens, full terminal layouts, multiple on-screen focus-able areas.

BeetleB 5y ago

Honest question: Do you have the same complaint about GUIs? As in, do you go to various Github pages for GUIs and make similar comments? Or is this expectation more for TUIs?

rektide 5y ago
I do think GUI programs should have machine-to-machine interfaces built in too, yes. I was young & barely knew it, but KDE's DCOP seemed like a very adequate way to script & control any app- that was awesome. Today on FreeDesktop, some apps do a good job of exposing themselves via DBus; music/media players in particular have very widespread support for the mpris interface, for example, but all sorts of apps expose control this way. The programming language Vala[1] in Gnome world has excellent DBus integration built in, so one can take some of their application models & expose them to the world, very much easing making m2m interfaces. [1] https://wiki.gnome.org/Projects/Vala/DBusServerSample#Type_Table https://wiki.gnome.org/Projects/Vala/DBusServerSample#Type_T...