I had also written something similar 5 years ago when I had jumped from heavy GUI usage to Linux for some linux commands, byusing their man pages, semi-automatically. Interesting enough, now I value the reverse more and I would love to see the Yeeog.
I've used them all to good effect, but I don't think it's fair to call them similar to Gooey. They require a bit of tinkering to work and your script has to adapt to running with a GUI. Zero effort to turn your ArgumentParser into a GUI is really a brilliant feature.
However, it is not for any command line program. It works only for python programs that use argument parser. Though, one can write a python argument parser around a cli to make it work.
Something similar could be done for Go. Since most of Go programs simply import the standard "flag" package for their command line parsing, you could have a pretty large coverage.
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.
Either way, it might be neat to do it dynamically, so command-line programs could be turned into guis live by typing "guify xyz".
The gui could have labels with the command options, and upon hitting enter they could close and send the command back to the command line, so you're learning the commands as you go.
I've done something similar to this a few times, both in Python.
Once to create a TkInter GUI for an internal command line app, and once to wrap sg3_utils for use in Python scripts.
In general, I think it could "mostly work" a good portion of the time, but it'd be pretty difficult to get working 100% of the time without a lot of tweaking to the parser.
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.
As much as I like the CLI, I really find this useful, because it takes time to go through document and find the desired option.
I think the real solution is that every CLI program comes with a description file (probably in XML) that describes its CLI options, their types, combination, etc.
The description file should help automatic GUI creating or shell completion.
The man pages are intended for human and are not meant to be specs. An advanced NLP program is required to parse man pages and infer appropriate types and combinations and I suspect it would not be perfect.
I agree that this might lead to something which is not in Unix spirit but already shell completion provide such information and this shows the need for such specs.
Finally something interesting to bridge the gap between GUI and CLI. What about a reverse operations ? so a `program` can be instanced in any situations without having to write separate (or too much) user input logic ?
I am using py2exe to convert my script into an executable.
but getting following error: File "commandui.py", line 1, in <module> File "gooey\init_.pyc", line 1, in <module> File "gooey\gooey_decorator.pyc", line 16, in <module> File "gooey\gui\base_window.pyc", line 16, in <module> File "gooey\gui\header.pyc", line 10, in <module> File "gooey\i18n.pyc", line 37, in <module> File "gooey\i18n.pyc", line 24, in get_path
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?
The picture in readme is one running a fake program I was using for testing. If you'll notice, none of the options particularly make sense -- heck, the output of the program (shown toward the bottom of the readme) is "printing message at: {hash}"
If you take another look at the readme, you'll see that it supports `choice` style params. Which reads in the options available and presents them to the user via a dropdown.
If you'll notice, none of the options particularly make sense
That's why I thought it was wrapping a real Linux command line program. ;)
If you're wrapping a CLI, there's not much more you can do than take all the CLI options and shove them into a 1990's style window peppered with options. But it's not helping anything - anyone who knows what the options are and do, and who is not put-off by heaps of options, is likely fine with the CLI version. Anyone who is offput by heaps of options isn't going to want to face them in CLI or GUI versions.
And anyone who doesn't like facing them, but who can deal with it, will wrap the CLI in a shell script that specifies the options they use most often and hides the rest.
The whole thing is missing how and why CLI and GUI programs are different. Chrome isn't a wrapper for WGET, Finder and Explorer are not wrappers for ls/mv/cd, and PhotoShop is not a wrapper screen full of toggle and dropdown options around ImageMagick.
Really pretty neat especially if your tool might be used by less technical folks. I can't count the number of times people in our engineering department have given non-technical people in our company a command line tool because its easier than adding a GUI, be it native or web. I think this will come in handy in those cases.
Yes, good idea ..! At our workplace, we have whole bunch of administration tool running on unix CLIs. I am thinking of way by which having same experience in browser based apps ..!
I'm wondering if such app can support some really complex unix cli apps. Like CLI app which runs(around 1500 commands)in fixed window on terminal and asks user input parameters.
That tool lets you describe a context-free grammar for the command line options, and transforms the options into gui elements. Does not require KDE anymore, compiles with Qt only.
http://kaptain.sourceforge.net/
That looks useful, particularly the supplied find and grep "grammar scripts". I installed Kaptain from the trusty/universe default Ubuntu repos and got the latest version. Only issue so far is that it installs to /usr/bin/kaptain and so the scripts need to be modified slightly (they expect bin in /usr/local/bin/).
Back in the days of the classic Mac OS, the Mac Programmer's Workshop included a tool like this, called "commando." One of the neat things about commando was that you could hover over any option to see some descriptive "help" info at the bottom.
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'm not sure quite what you're looking for, but you may be interested in my (not yet announced) docopt parser in C++: https://github.com/ridiculousfish/docopt_fish . It's got a richer feature set than the "reference" docopt.
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. I'm totally open to ideas (and pull requests) though! :)
I haven't looked at the code, but have you thought about abstracting out the bits that deal with argparse? Then people could write adapters for optparse, docopt, etc. Hooking into argparse the way you do is super cool, but it would be nice not to be limited to that.
> 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.
It's not meant to be a replacement for CLI. I can imagine lots of use cases, even for me. Example: I used something to bulk convert images (resize, crop, convert from one format to another). I used it maybe three times in my life, every single time I had to read the manual. If there was a simple GUI, I'd save time.
My main project is a mobile app that has a bunch of calculators dedicated to specific tasks. Some of this tasks are less-than-trivial, but most of them you'd not look a special tool for (for example VAT calculator). It has 950k downloads, most of its users are very happy with it. But every single time there's a review in the online press I get "this is for morons" comments. Every. Single. Time (unless it's a small blog that doesn't have commenters). When I saw Gooey, I had two thoughts: "Nice" and "Someone will surely try to make a point that this is stupid".
http://www.irfanview.com/ free image viewer for Windows, has "File" -> "Batch convert / rename" which can crop, resize, convert and so on.
I'm surprised you have settled on using a thing you dislike which doesn't work for you, when there are likely dozens or hundreds of wrappers, GUIs, APIs, programs and apps for image bulk editing to choose from.
As I've said, I only needed it a couple of times. Quickly Googled "batch image convert rename linux" or sth like that, saw which tool(s) I can use, checked the man page and I was done. My point was that if it had a simple GUI, I wouldn't have to read the man page.
_Settling_ on a solution indicates that a task is performed more often. In such a case, CLI is perfectly fine, because you learn how to use it while you do it and this knowledge sticks after several uses. I haven't used IrfanView, but I doubt it can compete with all the goodness of the command line.
I did not said it is stupid, I said you give up things if you use it.
Your use case perfectly makes sense, I did not thought about that! But I don't mind reading manuals since I got Dash[1] :)
I think the creator acknowledged this specifically:
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.
I was reminded of http://galaxyproject.org/ when I read this, which is a web front-end that goes between any number of HPC compute resources, data, command-line tools, and scientists.
Users assemble their workflows in a sharable, repeatable and somewhat easy-to-use way using the web-ified versions of their command-line tools. Galaxy takes care of hooking everything up (data, scripts, intermediate results, etc) and provides a UI for watching/controlling the resulting job(s) on the desired HPC cluster.
The goal for this in biology is to address the explosion in data modern biologists have to deal with nowadays - it's often completely overwhelming. Things like Galaxy increase both the accessibility of these command-line tools and also the large HPC compute resources traditionally dominated by users from the physical sciences.
Although it was a few years ago, it was rewarding seeing non-programmer users get onto HPC - importantly, while retaining control of their workflow - after they've struggled for so long on their local hardware. When you see jobs that took weeks or months run in hours or days, it's almost like giving a desert explorer some water.
Systems like Galaxy do require dedicated systems people to support it and make it properly sing though. Gooey could nicely accelerate the web-ification part of adding new software.
It's great that you're learning about the command line and you're enthusiastic about it, but what about writing software for the you of more than a couple of months ago?
I've written more than a few GUIs that added up to wrappers around a command-line app, this would have been very handy then.
