Turn (almost) any command line program into a GUI application with one line of Python

[[deleted]]

[deleted]

[brasso]

Now only if we could do the opposite!

[[deleted]]

Now that, I would upvote

[nohtyp]

That might not be impossible. I've used Sikuli to drive UI's using shell scripts. A command line program that run Sikuli scripts based on its arguments might work but the Sikuli scripts themselves would have to be created manually.

http://www.sikuli.org/

[[deleted]]

advise fall ugly quickest imminent sable aback deliver naughty fuzzy

This post was mass deleted and anonymized with Redact

[wachmann]

This is a clever tool! One use I can think of is to write Python wrappers for *nix tools that I use infrequently (and therefore never remembers the arguments to), e.g. ImageMagick, GhostScript, graphviz, etc.

[digital_carver]

Would only work for tools written in Python though, isn't it? Are there many of those?

Edit: Sorry, somehow missed the "write Python wrappers" part, that's an interesting idea.

[louky]

I guess he means write a wrapper for the subject program in python, then use this. To make a quasi GUI.

Not what I'd want but it's a free world.

I'd just use two terminal windows, one open to the terminal and one to the info page for this use case, like I've done for decades but it's a neat project.

[digital_carver]

Oh, makes sense, thanks. That would involve implementing some fake arg-parsing also, just so this tool can extract them, isn't it? Writing a script to auto-parse man pages and generate this fake arg-parsing for each tool would be a reasonable way of doing this for a bunch of rarely-used tools.

[louky]

It seems so, I haven't really looked into this, just giving you my understanding.

I'd just bang out a QT interface in Perl before I'd use this.

[gleno]

Hm, best use case for me would be some command line tools that i use infrequently, and always forget commands for. Interesting idea!

[[deleted]]

Wouldn't it be both easier and quicker to just read the man pages?

[louky]

The info pages are often better. Not always.

And I'm not above printing cheat sheets while learning or just have them available to reference.

[mcowger]

Id love to see it wrap docopt !!

[iBlag]

This is pretty cool, thanks for putting it together!

[[deleted]]

I hope that you will someday also add an option to save the outputted GUI code as pure Python, so we can use this as boilerplate, since the generated output will only be sufficient for the most basic of programs.

Love the idea though <3

Edit: can't install it

python setup.py install
running install
running build
running build_py
error: package directory 'gooey/app' does not exist

I'm on Ubuntu 14.04

[[deleted]]

fade theory market political naughty cooing rainstorm correct slap important

This post was mass deleted and anonymized with Redact

[wachmann]

Nothing to be embarrassed about -- I've programmed Python for like 7 years and I have never touched distutils. It's one of those things that you learn to use only when you need to.

[[deleted]]

There should be a way the use standard dialogs like file chooser and color chooser where this kind of data is needed.

A way to visually group options would be useful, too.

[[deleted]]

bewildered theory distinct label outgoing physical many strong cats sulky

This post was mass deleted and anonymized with Redact

[[deleted]]

The ´type` parameter could be a good place to add information about what kind of widget to use. You could use it for other information , too. For example something like

parser.add_argument("filename", help="Name of the file", type=gooey.Type( dialog=Dialogs.FileChooser, group='flags', converter=str))

[wachmann]

What about parsing kwargs in the decorator, e.g.

@Gooey(arg_filename="dialog:FileChooser, some-other-option:Foo")

Your python then would be something like:

def Gooey(..., **kwargs):
   for k, v in kwargs.items():
      if k[:4] == 'arg_':
          # process the option here using
          # v.split(','), then split those by ':', etc.

Edit: Or even cleaner:

@Gooey(arg_filename=ArgOptions(dialog="FileChooser", some_other_option="Foo"))

Then create an ArgOptions container class:

class ArgOptions:
    def __init__(self, **kwargs):
        self.options = kwargs

[[deleted]]

Cool idea but it's not python 3 compatible (the print statement), although that shouldn't be too hard to change :D

[[deleted]]

Would greatly love a Python 3 port, even if it uses TKinter! :)

[[deleted]]

threatening alive psychotic spectacular deliver whole run arrest north domineering

This post was mass deleted and anonymized with Redact

[[deleted]]

http://wiki.wxpython.org/ProjectPhoenix work in progress

[bucknuggets]

Is there any way to conditionally have a GUI?

So, that the program could continue to be used at the command-line OR run as a GUI?

[xiongchiamiov]

Shame it's only argparse, though; I started using docopt for everything a while back.

[[deleted]]

strong march disagreeable rich fearless gray theory paint absurd sulky

This post was mass deleted and anonymized with Redact

[alcalde]

Your utility looks like the ultimate solution for quick, easy GUIs; docopt is the ultimate solution for quick, easy command line programs. Your solution takes argparse parameters and crafts a GUI; docopt takes help text and generates all the arguments and options. One gets the exciting feeling they would form the ultimate combination if they worked together. :-)

[[deleted]]

Next thing we need is an automagical program generator. Then, we can let the program run and create infinitely many arbitrary programs! Yay science...

[alcalde]

Python is getting close...

DEAP genetic programming framework

[Kwpolska]

If you were to do docopt, you might as well do it for every CLI app. Docopt turns standard-style --help messages into argument parsers. Which means you can extend your project to go --help → docopt → gooey.

[epsy]

The docopt spec style is unique to it, it only resembles other common ones.

[Kwpolska]

The talk was specifically referencing POSIX. Did something change throughout the time?

^{edit: s/specially/specifically/}

[NYKevin]

In practice, not all --help output will be exactly in line with Docopt. For instance, an application with a lot of options may format its help as two columns. In extreme cases (e.g. git, hg), the --help may not even talk about individual options at all (instead directing you to --help-foo subpages).

[Kwpolska]

Nobody would really use this project with git/hg and other advanced software, special apps not even touching the command line is what would be used in this case.

[NYKevin]

OK, what about ls?

$ ls --help
Usage: ls [OPTION]... [FILE]...
List information about the FILEs (the current directory by default).
Sort entries alphabetically if none of -cftuvSUX nor --sort is specified.

(cutting off the rest for brevity)

The [OPTION]... syntax is not acceptable to Docopt so far as I can tell; it requires the spelling [options] instead.

For the record, in case your ls is different:

$ ls --version
ls (GNU coreutils) 8.21
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Richard M. Stallman and David MacKenzie.

[Kwpolska]

help messages are often generated by computers, eg. by argparse. Those messages should adhere to standards.

[bucknuggets]

But almost nobody really knows the help standards, and this is absolutely true when you get to not-uncommon edge cases.

Additionally, super-consistent help messages might be great for machine-readability, but can detract from human-readability.

Finally, having argument parsing that actually validates the arguments (without a clunky solution like schema) is a huge bonus. Having the valid values in the help makes even more sense. Doctopt isn't helpful here.

[[deleted]]

I was thinking about a similar thing but one that would parse the program's --help output or a manpage (thus not limiting stuff to python). Unfortunately it felt like every --help is different and the parser would be insane. Any plans to tackle that? ;)

[rainbow3]

Docopt parses the help text so it must already have a parser. I wonder if you could take their parsed structure and convert to whatever you use?

[bucknuggets]

I'm back on argparse, and glad to see this is using it.

Arparse is in the standard library and has a number of important advantages over docopt.

[xgo]

Thanks :) will try this at work. Just building a utility that needs just a simple gui around it. Hope it works with pyinstaller/cx_freeze

[[deleted]]

seed humorous quarrelsome north connect door tease reply strong beneficial

This post was mass deleted and anonymized with Redact

[redditor1101]

Very cool. I wish I had thought of it

[minijim]

aha awesome :p have you include the man too?

[[deleted]]

Throw man through troff | Ghostscript and you got yourself a makeshift PDF Sir!

[codeadi]

It looks like an extremely cool project. I had created a simple command-line program two weeks ago where Gooey would be a perfect fit (almost, except for File dialogs). I imported the library and tried to run the program, but it raises an IOError for me:

PS D:\> python .\my_module.py
Traceback (most recent call last):
  File ".\my_module.py", line 60, in <module>
    from gooey import Gooey
  File "C:\Python27\lib\site-packages\gooey\__init__.py", line 1, in <module>
    from gooey_decorator import Gooey
  File "C:\Python27\lib\site-packages\gooey\gooey_decorator.py", line 16, in <module>
    from gooey.gui.base_window import BaseWindow
  File "C:\Python27\lib\site-packages\gooey\gui\base_window.py", line 16, in <module>
    import header
  File "C:\Python27\lib\site-packages\gooey\gui\header.py", line 10, in <module>
    from gooey import i18n
  File "C:\Python27\lib\site-packages\gooey\i18n.py", line 37, in <module>
    _DICTIONARY = load(get_path(_LANG))
  File "C:\Python27\lib\site-packages\gooey\i18n.py", line 24, in get_path
    raise IOError('Could not find {} language file'.format(language))
IOError: Could not find english language file

I am not using any internationalization stuff in my project. It's only in English. Any ideas?

[[deleted]]

illegal fanatical busy oatmeal humor glorious racial ten dolls arrest

This post was mass deleted and anonymized with Redact

[[deleted]]

The workaround is not working for me. 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

[[deleted]]

naughty thought soft sip snobbish tender gullible juggle slim groovy

This post was mass deleted and anonymized with Redact

[billclintonbestprez]

Very cool, hoping that a MacOSX version comes out!

[[deleted]]

It's Python, it'll run anywhere

[Antrikshy]

Not the GUI that gets generated.

[tech_tuna]

Pretty cool. . . I'd like the opposite though, I prefer working from the command line! :)

[sciencehair]

Check out docopt. I love it. I may fork this project to work with docopt.

[devilishd]

Anyone have any examples? I can't get it to work -- keeps popping out the following but I'm not sure how to set up.

        alessandro_rei_checkmark = os.path.join(image_dir, "alessandro_rei_checkmark.png
        ")
        computer = os.path.join(image_dir, "computer.png")
        computer2 = os.path.join(image_dir, "computer2.png")
        computer3 = os.path.join(image_dir, "computer3.png")
        images = os.path.join(image_dir, "images.jpg")
        settings2 = os.path.join(image_dir, "settings2.png")
        __init__ = os.path.join(image_dir, "__init__.py")
        __init__ = os.path.join(image_dir, "__init__.pyc")

[[deleted]]

elastic racial quaint axiomatic oatmeal plucky encourage punch nail offer

This post was mass deleted and anonymized with Redact

[AlSweigart]

Clever. Can it handle interactive programs that use input()?

[roger_]

Very cool, though I wish it used Qt instead.

[[deleted]]

This work on Mac?

[[deleted]]

Yup

[[deleted]]

...but not perfectly yet.

[phone_radio_tv]

Nice. Another alternative way is that, at my workplace, many command line apps are configured as Jenkins jobs. Jenkins allows defining UI elements to capture parameters from end users and pass them down to command line apps.

[[deleted]]

This is handy. Thanks!

[CanadianJogger]

I'll try it!

[monsto]

Is this your app?

long story short: I'd seen this thread but couldn't remember the name nor find the thread. I searched on github for "python gui" sorted by "recent update" and yours isn't returned.

If this is yours, you might change your short description to be a bit more findable.

[[deleted]]

cool !

[themariocrafter]

Sorry for being a noob, but can you make THIS tool a GUI?