4 ms·

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.

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.