6 ms·

With all these command-line parser libs, I'm surprised there aren't more libraries that automatically generate a graphical interface for them. Would be super us

With all these command-line parser libs, I'm surprised there aren't more libraries that automatically generate a graphical interface for them. Would be super useful for e.g. ffmpeg, cc, curl, etc. Especially for people unfamiliar with the program....

blackbear_ 3y ago
There is for Python: https://github.com/chriskiehl/Gooey https://github.com/chriskiehl/Gooey
indymike 3y ago
Early on (late 90s and early 00s) there were a lot of command line to gui kinds of tools (there were also a lot of tries at web-ifying, CLI tools also). I can't remember the name, but there was even a terminal emulator that tried to present commands as dialogs. * There is no enforced standard for commands other than using a file name to invoke them. * Different languages and frameworks have different and multiple ways of parsing command lines. For example Gooey (a python gui tool) works with scripts written with the argparse library but dodes not work with optparse. * The terminal is not the shell. That means that to present a gui, you'll have to launch something that runs outside of the terminal to present the gui. * It's common for developers to write command line tools with out understanding the shell and os's input and output system beyond reading and writing files. I routinely have to teach jr developers about stdio, stderr, pipes etc... That said, there's great potential to take advantage of shell autocomplete files to make better guis for commands: https://blog.deepjyoti30.dev/tab-autocomplet-cli-apps https://blog.deepjyoti30.dev/tab-autocomplet-cli-apps . Someone probably already has done this...
- JeffSnazz 3y ago
  The idea is that you'd build it into whatever command-line parsing tool you use. Presumably this would be runtime-specific. And yes, the entire point is to escape the terminal and rely on native interface constraints (e.g. disabling/enabling) to reflect the usage of the tool.
  - indymike 3y ago
    > whatever command-line parsing tool you use Hmm. Writing a wrapper that uses autocomplete definitions might be more useful... There's also the approach of Zenity that gives you the ability to create GUIs from shell scripts. When you do have a gui from parser tool, it can be quite nice (like Python's gooey).
CubsFan1060 3y ago
https://github.com/Textualize/trogon https://github.com/Textualize/trogon
PurpleRamen 3y ago
It doesn't even need to be a full GUI, just having an interactive interface for weaving commandline-spells on the fly would already improve the access. But then again, this would demand a more complex interface than a commandline. I'm not sure how easy this is implementable with your average shell&terminal.
- mooreds 3y ago
  There are some reasonably complex git tuis. https://github.com/extrawurst/gitui https://github.com/extrawurst/gitui is one
arccy 3y ago
a good shell completion function is like 80% of the way there, it can even include descriptions for flags, and the smart ones will know about exclusions and such

blackbear_ 3y ago

There is for Python: https://github.com/chriskiehl/Gooey https://github.com/chriskiehl/Gooey

indymike 3y ago

Early on (late 90s and early 00s) there were a lot of command line to gui kinds of tools (there were also a lot of tries at web-ifying, CLI tools also). I can't remember the name, but there was even a terminal emulator that tried to present commands as dialogs. * There is no enforced standard for commands other than using a file name to invoke them. * Different languages and frameworks have different and multiple ways of parsing command lines. For example Gooey (a python gui tool) works with scripts written with the argparse library but dodes not work with optparse. * The terminal is not the shell. That means that to present a gui, you'll have to launch something that runs outside of the terminal to present the gui. * It's common for developers to write command line tools with out understanding the shell and os's input and output system beyond reading and writing files. I routinely have to teach jr developers about stdio, stderr, pipes etc... That said, there's great potential to take advantage of shell autocomplete files to make better guis for commands: https://blog.deepjyoti30.dev/tab-autocomplet-cli-apps https://blog.deepjyoti30.dev/tab-autocomplet-cli-apps . Someone probably already has done this...

JeffSnazz 3y ago
The idea is that you'd build it into whatever command-line parsing tool you use. Presumably this would be runtime-specific. And yes, the entire point is to escape the terminal and rely on native interface constraints (e.g. disabling/enabling) to reflect the usage of the tool.
- indymike 3y ago
  > whatever command-line parsing tool you use Hmm. Writing a wrapper that uses autocomplete definitions might be more useful... There's also the approach of Zenity that gives you the ability to create GUIs from shell scripts. When you do have a gui from parser tool, it can be quite nice (like Python's gooey).

CubsFan1060 3y ago

https://github.com/Textualize/trogon https://github.com/Textualize/trogon

PurpleRamen 3y ago

It doesn't even need to be a full GUI, just having an interactive interface for weaving commandline-spells on the fly would already improve the access. But then again, this would demand a more complex interface than a commandline. I'm not sure how easy this is implementable with your average shell&terminal.

mooreds 3y ago
There are some reasonably complex git tuis. https://github.com/extrawurst/gitui https://github.com/extrawurst/gitui is one

arccy 3y ago

a good shell completion function is like 80% of the way there, it can even include descriptions for flags, and the smart ones will know about exclusions and such