We use it in combination with Python Fire [0] to easily convert python code to something that users can interact with. Python fire converts our python code into a CLI without all the manual parameter parsing, and Gooey turns the CLI into a simple GUI.

[0] https://github.com/google/python-fire

Today I learned about Fire AND Gooey

Sometimes I get bogged down in writing proper argparse when it really is not needed.

Are there any edge cases where Fire does not work too well, like some strange parameters (for example tuple as dictionary key)?

[0] https://github.com/tiangolo/typer

So we have one file which contains the class with all the functions we want to expose (in our case, the class is named JobManager). At the end, it goes

    if __name__ == '__main__':
        fire.Fire(JobManager)

Then we have a second file for the GUI, which has a main-function that does some argparse stuff. The GUI interface is simplified from the CLI interface, so it's not that much work to write the argparse code for that. Simplified, it looks a little like this :

    @Gooey(default_size=(1000, 600))
    def main():
        parser = GooeyParser(description="jobGUI")
        # argparser code
        args = parser.parse_args()
    
        JobManager(args.name, args.whatever)
    
    if __name__ == '__main__':
        main()

    if __name__ == '__main__':
        fire.Fire(JobManager)

Then we have a separate gui.py file, which contains the Gooey code. This includes the class mentioned above, and builds a minimalistic GUI around it. This does need some argparse-based code, but in the GUI we only expose a small subset of the full power, so we only need a little bit of argparse-code.

P.S. I'm not certain this is the best way to approach things, but it's the way we use it, and we're happy with it so far.

It mostly works great. If you have a complicated UI with multi-selects, validations and default selections, it probably isn't for you. But if you really just need a desktop UI for a script, it does what it says. You can make a UI in a few minutes.

There's also Wooey - a web-based take on the same idea if you need a Django web app to queue up and run your scripts. That implementation is a little more janky, but it also mostly works.

There's a section on pyinstaller in the github page, but my experience is that this domain (packing a Python application into an executable) is hard, dirty and inefficient all around, so I'd appreciate having the opinions of people who tried it beyond toy problems

I can't seem to find an answer to this in the docs - only implicitly, in that they only show Windows screenshots.

The Gooey docs do mention mac: https://github.com/chriskiehl/Gooey/blob/master/docs/packagi..., and there's some code in the repo written specifically for Linux, so I think it ought to work.

Not sure about mac, but it certainly should as well.

Also: whoa, didn't expect to see my project on the front page of HN this morning! ^_^

I laughed at >>> Because as much as we love the command prompt, the rest of the world looks at it like an ugly relic from the early '80s. <<<

I didn’t use direct capture of stdout because it’s useful to have first class support in the web UI for other types of data, like tables, where you want sort/filter/save to csv. Colors are simple if you interpret those ascii control codes. I did some long polling with incremental data fetch so huge and/or long-running commands work efficiently. Works a treat. Totally worth the investment.

Next step would be to pitch the boss about the usefulness of open source as a recruiting tool, and get some time budget for this kind of stuff.

Reading https://github.com/chriskiehl/Gooey#how-does-it-work

One simply attaches a decorator to whichever function/method your argparse uses.

I have dozens of argparse based programs that could use Gooey.

I wonder if it could be extended for almost all command line applications by running "--help" and parsing the output. It's not quite as standardized as programmatic access to argparse but there aren't that many variations.

[1] https://palletsprojects.com/p/click/

https://github.com/jely2002/youtube-dl-gui

https://itsfoss.com/youtube-dl-gui-apps/

We have a big list of youtube-dl GUI's over on /r/youtubedl's wiki: https://www.reddit.com/r/youtubedl/wiki/info-guis

That was silly, but this makes sense for 1-offs. You write an internal CLI, realize the userbase isn't technical enough for it, and strap a GUI to it.

I've hit that plenty with things I made for an ops team that eventually got shifted to more BA/PM-types. I've usually turned them into a web-app, but it's a lot of lifting and a "thick client" approach would be nice.

I am spoiled, though, with Click, and don't ever want to go back to argparse, though. I'll keep an eye on it, though.

>There's also Wooey - a web-based take on the same idea if you need a Django web app to queue up and run your scripts. That implementation is a little more janky, but it also mostly works.

https://docs.raku.org/language/create-cli#sub_MAIN

The point Gooey is to use the definition of the arguments (which we could call the program command-line grammar) to automatically build an UI.

But I see much more potential for the Raku world where there is built-in syntax for declaring arguments with strong typing. https://docs.raku.org/language/create-cli#sub_MAIN

But I'm thinking about something similar for any program that provides shell completion scripts: it would have to parse the shell completion definition to build the UI.

The utilities I mentioned let you create UIs for shell scripts with ease.

I'm not even jealous.. kudos

[0] https://github.com/bw2/ConfigArgParse

https://github.com/theskumar/python-dotenv

[0]https://github.com/chriskiehl/GooeyVideo

Sometimes one script is just not enough/not convenient enough, and I write simple helper wrappers such as:

- https://indiscipline.github.io/post/movie-thumbnailer-announ...

- https://indiscipline.github.io/post/ffmpeg-loudnorm-helper-a...

https://www.shutterencoder.com/en/

> flags are inconsistent

At least among the core command set, there is a set of "core flags" like -ErrorAction or -Verbose that are consistent. Though I don't know how often you'll find them in third-party commands.

> case sensitive

There's a preferred case that you'll get if you tab complete, but -Verbose is -VERBOSE is -VERBOSE.

> not good discoverable

Tab completion works for flags everywhere and each of them should be included in Get-Help regardless of if the author documents them.

My 12 year old is doing a fair bit of video work, and I just pointed him at Handbrake to get his submission file size down. It's an amazing bit of software, apart from that malware issue back in 2017...

catt lets you Chromecast direct from your local machine, which could be of interest to non-techies, but catt only ships with a command-line interface. (Although I believe an unofficial GUI exists that doesn't use Gooey.)

I wrote a brief guide awhile ago here[0]. For instance, all the screen shots and screen recordings throughout the README are done with a custom wrapper I made with Gooey which just acts as a pretty 'front end' for FFMPEG[0]

[0] https://chriskiehl.com/article/gooey-as-a-universal-frontend [1] https://github.com/chriskiehl/GooeyVideo

Gooey works with Fire, though.

    @Gooey()
    def main():
        fire.Fire()

    def hello(name="World"):
        return "Hello %s!" % name

    if __name__ == "__main__":
        main()

Instead of having to go back and forth between the --help output or a man page and the command you're typing, you can just read as you go.

This is great for non-trivial tools used occasionally by people who don't live in the terminal (aka most users).

Because they have no experience using a terminal, entering commands and finding documentation

For example to provide quick tools for non-professional users.

Single button automation for scripts that need to be run intermittently and are poor candidates for timed execution.

I am quite proficient at command line, but still prefer a single button that "does that one thing I need".

A command-line interface to clicking buttons on a headless GUI, by naming their labels, would be an extremely useful tool. Even if only worked for applications written with the major toolkits gtk, qt, electron etc.

EDIT: imagine that you could do this:

    ungooey gimp --menu file:open:lena.png --click eraser --drag "10,10-100,200" --menu file:saveas:lena2.png

most likely both Windows and macOS would have similar mechanisms for accessing their respective accessibility api

https://en.wikipedia.org/wiki/AppleScript