31–40 of 76 posts
Good idea. I wonder if anyone has done this for general unix command-line apps by parsing out the man pages on the fly. It probably wouldn't work for all programs but may be gnu style ones would be consistent enough.
Good idea. I wonder if anyone has done this for general unix command-line apps by parsing out the man pages on the fly. It probably wouldn't work for all programs but may be gnu style ones would be consistent enough.
Not far from that there's docopt who parses POSIX compliant arguments descriptions.
Really awesome and promising idea, but I think the implementation is limiting. Couldn't it just as well parse help text? It's not guaranteed to be standard, but there are probably more programs that can be parsed that way than use ArgumentParser.
I actually started out just parsing the help text, but ArgParse gives a ton of extra options that let me better choose the widget type. For instance, things like `Choice` or `Count` options which cue the framework to use dropdowns. Or `StoreTrue` which cues it to generate a CheckBox. Stuff like that. I'm not totally sure how I could get that level of detail without forcing some kind of markup within the help messages…
Earlier quoted context omitted.
Not far from that there's docopt who parses POSIX compliant arguments descriptions.
Is there such a thing as POSIX-compliant argument descriptions? I know POSIX specifies some things about the format of options, but I didn't realize there was a formalized option description language.
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_...
This is actually how Docopt happened (Vladimir Keleshev mentioned it in the PyCon UK 2012 talk).
and lose the ability to pipe, check exit status, run from cron, run through ssh or a different machine, call from other scripts...
The last couple of months as I know about more and more the command line, and can configure my shell and tools the way I like, I feel I'm more productive with the terminal than any other GUI application.
Encoder (-e). OpenCV FOURCC Type. {Empty text box}.
Just take all possible options and ... shove them right in the user's face. Is that user friendly? Whom is it helping, who doesn't want a CLI but also knows how the CLI program works, but also can't script it?
> Turn (almost) any command line program into a full GUI application with one line and lose the ability to pipe, check exit status, run from cron, run through ssh or a different machine, call from other scripts... The last couple of months as I know about more and more the command line, and can configure my shell and tools the way I like, I feel I'm more productive with the terminal than any other GUI application.
If you're building utilities for yourself, other programmers, or something which produces a result that you want capture and pipe over to another console application (e.g. nix philosophy utils), Gooey probably isn't the tool for you.
It's still helpful though for other scenarios.
Really awesome and promising idea, but I think the implementation is limiting. Couldn't it just as well parse help text? It's not guaranteed to be standard, but there are probably more programs that can be parsed that way than use ArgumentParser.
http://docopt.org/ This project attempted to make argument parsing and the help string synonymous. I'm not sure if it is being actively maintained.
I tried to write a docopt to click converter but I had to give up.
