Gooey: Turn command line programs into GUI applications(github.com)
github.com
Gooey: Turn command line programs into GUI applications
https://github.com/chriskiehl/Gooey
75 comments
Can we have a "Restart" button using last arguments.
That will be a great addition and really really useful.
Good idea! I'll add it to the TODO.
Really cool. May try to make something like this for jCommander.
Clever.
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.
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.
Very cool!
Does anything similar exist for Android ?
I would love to use some bash scripts but I don't find the terminal editors I tried practical.
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.
There are tools, at least on Unix, to add guis to command lines. gtkdialog and zenity are the ones I've seen.
You need to write a shell script that runs commands to display the gui, and then execute the command.
You need to write a shell script that runs commands to display the gui, and then execute the command.
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.
This project attempted to make argument parsing and the help string synonymous. I'm not sure if it is being actively maintained.
Nice find! https://github.com/docopt/docopt.go was updated 18 days ago, so it does look alive and well.
The problem with docopt is that it's very hard to process internally. There is no real internal representation.
I tried to write a docopt to click converter but I had to give up.
I tried to write a docopt to click converter but I had to give up.
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'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.
How about converting CLI programs into Web based applications ?!!
With a REST API you can call from curl !?
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 ..!
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.
I too was expecting something like what you describe but by parsing -h --help output.
The bash-completion script can deduce which options are supported by an application by parsing the output of --help and of usage lines. In Bash.
http://anonscm.debian.org/cgit/bash-completion/bash-completi...
http://anonscm.debian.org/cgit/bash-completion/bash-completi...
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.
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.
The Python "argcomplete" module[1] generates shell completions for any program that uses argparse, so it's certainly doable.
[1] https://github.com/kislyuk/argcomplete
[1] https://github.com/kislyuk/argcomplete
> parsing out the man pages
https://github.com/idank/explainshell
https://github.com/idank/explainshell
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.
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.
The fish shell does this with an explicit command (fish_update_completions) and offers an awesome Tab completion in the current Github version
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.
Yes. IEEE Std. 1003.1 Utility Conventions
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_...
This is actually how Docopt happened (Vladimir Keleshev mentioned it in the PyCon UK 2012 talk).
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_...
This is actually how Docopt happened (Vladimir Keleshev mentioned it in the PyCon UK 2012 talk).
Cool! Thanks for the reference :)
Me neither, I thought docopt was a hardcoded fragile thing, until the author explains everything is almost perfectly defined.
That looks awesome. Are there similar implementations native to other languages out there?
Something similar for creating GUIs on Mac OS X http://www.bluem.net/en/mac/pashua/
I'm so glad this is made using python :) I can now hack it to my heart's content.
Looks like the perfect companion to click: http://click.pocoo.org/
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.
http://i.imgur.com/Zxx33DU.png
http://i.imgur.com/Zxx33DU.png
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 ?
so neat
> 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.
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".
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.
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.
_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] :)
[1]: http://kapeli.com/dash
[1]: http://kapeli.com/dash
You're right, you didn't. Sorry for insinuating you were. Thanks for the Dash link, looks great :-)
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.
It's still helpful though for other scenarios.
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.
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.
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.
[deleted]
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.
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.
"Transform your command line apps into user friendly GUIs" - https://raw.githubusercontent.com/chriskiehl/Gooey/master/re...
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?
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?
Yeesh.
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.
So, friendly options are a'plenty! :)
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.
So, friendly options are a'plenty! :)
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.
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.
Hmm.. Guess we just have different experiences with the user base this is targeting.
Similar workflow for Macs: http://www.sveinbjorn.org/platypus + http://mstratman.github.io/cocoadialog/ or http://www.bluem.net/en/mac/pashua/
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.
Yeoog; Turn GUI programs into command-line
Yeoog; Turn GUI programs into command-line
I too would love to see a Yeoog
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.
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 description file should help automatic GUI creating or shell completion.
I think you just described a man page. Except for the xml part. That sounds a lot more like something MS would do.
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.
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.
If only there were an IEEE standard for utility conventions.
I assume you are referring to the POSIX spec on utilities (http://pubs.opengroup.org/onlinepubs/9699919799/), which is helpful but not a full solution to the problem.
Nice. I think this will help me get motivated to start developing GUI apps. Thank you.
Another app in this vein was Kaptain (for KDE):
http://sourceforge.net/projects/kaptain/
http://sourceforge.net/projects/kaptain/
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/).
Implementing an api compatible wrapper around argparse might have been simpler than parsing the source code.
Beautiful idea. I can see this can be a great front end for wget/curl.
I was expecting it to merely be a graphical version of "dialog". I was pleasantly surprised!
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
IOError: Could not find english language file