I've been using this to wrap CLIs for internal tooling at my company [it's also my first accepted contribution to a FOSS project =D ]. Works well, but subject to the usual Python packaging issues. If I needed to wrap a CLI with a GUI for my users, that probably means I don't want to walk them through installing Python and dependencies either. That means using something like PyInstaller, which I can report plays well with Gooey.

Isn't the idea here that you're getting a binary at the end of it that doesn't require any of the dependencies? or do you need the full environment?

I don't think I'm understanding your question, and maybe I haven't laid down the situation fully.

My company is a Windows shop, and nearly everyone who isn't a developer (so nearly my entire internal customer base) does not have Python installed.

I want to be able to send over single file executables that have everything they need. I don't want to have to think about using pip, or distributing wheels, or making sure they have internet access, or if they have admin or not. And as internal tools, I can afford to deal with relatively large file sizes.

For example, I have a lot of tools that need numpy and scipy to accomplish their goals.

That all said, Gooey + PyInstaller typically does a good job at solving my problems.

I think what he was asking was, could there be some way of packaging a .exe with a full python environment and all dependencies built in (and so zero install basically)?

Edit: after reading the docs for pyinstaller, it seems that this is exactly what it does. vxNsr was either confused about what gooey does, or, like me, got confused by the name "pyinstaller" and assumed it was a tool to help you install a python environment on Windows.

Yes, you can compile the python script/program to a windows exe file. It is quite large cause it has to also include all dependencies. However it does work. Can't remember what I used but a quick Google search would bring it up.

I believe it's called pyinstaller

gooey via python would require a full python environment. pyinstaller bundles everything (including the python runtime) into a fat .exe to "solve" that.

I use zenity

I didn't know about Zenity, thank you.

https://help.gnome.org/users/zenity/3.32/

Never heard of this, but I once wrote a Perl script (it was a long time ago ;-) that created Perl/Tk UIs around CLI tools by parsing the output from "$CMD --help" or "man $CMD".

It never worked perfect, but was "good enough" for the few simple things I needed it for.

This is neat to see on Linux, it reminds me of Platypus on OS X [1], which in turn drew spiritual inspiration (that is, I don't know if the author of Platypus knew about these) from CLImax [2] and even earlier, Macintosh Programmer's Workshop [3] [4]. I don't know where MPW got the idea from, that just happens to be where I first encountered it. Thanks to user classichasclass in this thread for reminding me that the feature was called Commando in MPW. I'm curious if it originated with MPW.

[1] https://sveinbjorn.org/platypus

[2] http://www.storiesofapple.net/climax.html

[3] http://www.storiesofapple.net/tag/mpw

[4] https://www.semanticscholar.org/paper/The-Macintosh-Programm...

I'm not a big fan of GUI in general but, ooo, this is nice.

Combine with python-fire for great fun, eh?

> Python Fire is a library for automatically generating command line interfaces (CLIs) from absolutely any Python object.

https://github.com/google/python-fire

It's Commando for a new generation.

http://preserve.mactech.com/articles/mactech/Vol.06/06.07/Co...

I was looking to see if Commando would get mentioned. One of the really nice things about Commando was that it would synthesize the command line for you and not just run the command, and it was integrated with the MPW editor. So you could go through the GUI for a program, press a button, and the command-line invocation is pasted into the script you’re editing.

MPW was ahead of its time in a lot of ways, unfortunately behind its time in a couple ways (notably, pipes didn’t work the way they did on Unix—I think there was something like temporary files involved).

Here is the article with intact screenshots: https://web.archive.org/web/20000819105036/http://mactech.co....

Yes!!

Commando was also part of A/UX. Here's a screenshot of Commando for the "ls" command: http://toastytech.com/guis/auxcmdo-ls.png

Looks extremely cool. I used to enjoyed developing GUIs with WinForms but now as this technology is obsolete and no relevant replacement is available (both web-UIs and Qt are too complex and WPF is Windows-only) this seems extremely attractive. Can it also display progress and output data (a matplotlib plot and/or a data table)?

Yep! ^_^

When you're setting up Gooey, you can tell it what kind of output track in stdout, and how to interpret that as progress. We've got a few examples in this repo: https://github.com/chriskiehl/GooeyExamples/tree/master/exam...

Matplotlib works a-ok as well!

Cool! Can it also let the user to send the result to a printer (I personally am interested the PDF virtual printer) or save it to a text file (if it's text)?

Not currently. However, the last release did just add a menu system, which would be a nice candidate for these kinds of IO behaviors!

If you're interested, do you want to open a feature request here? https://github.com/chriskiehl/Gooey/issues

Made a feature request: https://github.com/chriskiehl/Gooey/issues/472

Are there examples on other operating systems?

WinForms are actually back from the dead. They are part of .NET Core 3, coming this week.

If it's in .NET core, does this mean that WinForms will become cross platform (without having to use Mono)?

Looks line no, unfortunately

> To be clear, the Windows Desktop component is only supported and included on Windows.

https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotne...

If only Microsoft cared to listen feedback a bit... the lack of a cross-platform UI (which existed for a while with Silverlight) is what is dragging back the whole .net ecosystem from wider adoption.

Unfortunately no, though I believe there are other attempts at cross platform GUIs whose names I can't remember at the moment...

Uno [1] and Avalonia [2]?

[1]: https://platform.uno/

[2]: https://github.com/AvaloniaUI/Avalonia

If you like WinForms, take a look at Eto (https://github.com/picoe/Eto)

"This framework can be used to build applications that run across multiple platforms using their native toolkit, with an easy to use API. This will make your applications look and work as a native application on all platforms, using a single UI codebase."

Thank you, I'll take a look, but it hardly is a real replacement. Honestly, I liked WinForms because it had a visual designer where I could just paint the UI with a mouse, click a button and code what's going to happen when it's clicked. Nevertheless anything like WinForms probably is easier than web-based UIs, even if it lacks a visual designer. However, one should probably prefer Avalonia (a cross-platform WPF-like .Net UI toolkit) if going this way.

It remind me SWT in Java. It used native graphical window management when the web was still not a thing. I made one of school project with it...

How does Eto compare to the very mature wxWidgets?

Looks like a variant of dialog[1] and its many X11/gtk/qt/etc forms.

What was nice about dialog was that it was called to collect input by the application, so the application could ask (from a ui) some input, then later on ask for or display something else. Does Gooey support the same sort of use case?

[1] https://www.linuxjournal.com/article/2807

Things that might be generally useful for cli programs:

creating GUI interfaces for them (what this does)

enhancing CLI interface to include autocomplete including help with options and arguments

wrapping CLI commands to turn them into APIs/make them programmable

> wrapping CLI commands to turn them into APIs/make them programmable

CLI apps are already very programmable. How would you API-ify them even more?

  system('yourapp --option1 --option2=something')

Avoiding entire classes of escaping/parsing vulnerabilities.

By burying them in the framework....

Yes, exactly, just like database query processing in ORM systems and the like "buries" SQL injection countermeasures in a single place. It's a good thing.

There's abstraction confusion here, though. All SQL injection countermeasures and all it would take to protect the above CLI call is respecting the actual language you're using. That is, not gluing a query/command from strings.

Starting a subprocess via shell is could in particular be solved by a simple API of the form of:

  system('yourapp', ['option1', {'option2' : 'something'}]);

in your favourite language. Handling pipes and redirects gets more complex, but I see no prima facie reason why it couldn't look like this:

  pipe(system('yourapp', ['option1', {'option2' : 'something'}]),
       system('grep', ['n', 'i', 'foobar']),
       system('somethingelse', [], null, file("/dev/null")));

This assumes the --option=value syntax which while a de-facto standard on Unix-like systems is unfortunately not supported by all programs.

I agree that system() (in C and other langues that simply copied it) is a bad API. For shell escaping a command to start a process with a list of arguments would be enough, and even POSIX C has you covered there with vararg and array variants. [1]

[1] http://man7.org/linux/man-pages/man3/posix_spawn.3.html (or fork() + exec())

Input and output types would be a good start.

Powershell kinda does this, but people are still debating if it's a good thing or not.

(personally, I think it is, and helps give structure to the sometimes too "dynamic" world that is shell scripting)

--output=json

That isn't a type, but I like the direction you're going.

Shouldn't all programs be written as APIs anyway? Than you can add a command line interface or a graphical interface on top as wished.

Cool! I'm wondering if there's any possible way to automatically generate GUI's for command line applications. Including all the supported arguments.

Some type of crawler would interact with a program, parse its --help output, man page, or any other info available, to enumerate all possible options and their formatting.

It sounds like a really messy program considering how inconsistent CLI's are.

Anyways, a GUI could help massively with discoverability.

Such a tool could help bridge the gap a little between GUI and CLI.

Barring that, a community-curated repo of interfaces for common applications would also be great. You could just have a wrapper that automatically downloads the applicable config files on the fly.

I can’t see how that would handle any of the hard bits (like dependencies between arguments, mutual exclusion)...

To the extent the command-line program returns proper exit codes, or gives other hints via its output/side-effects as to whether it did anything useful, I could see it working up-to-a-point.

Discovering exclusive options, or options that must be specified together, sound like exactly the sorts of things it could deduce, when every invocation with/without certain pairs of options fails.

Perhaps wrapper-utilities like 'Gooey' or some sort of automated-probing could encourage a greater formalization for specifying de-facto command-line APIs. Then, command-line programs might want to offer not just the human-interpretable help texts and docs, but more rigorous usage-specs that could drive automatic wrappers.

Probing at options sounds dangerous. There is no guarantee at all that attempted invocations won't change state.

I wouldn't wanna let it probe 'rm' :D

Perhaps the probing could happen in a VM / container image which would reset after each invocation.

You'd of course do it inside a controlled environment, via virtualization or similar technologies which let you monitor, veto, or roll-back anything the analyzed program does. (And if it's malicious/sneaky enough to escape that, then it wasn't safe to use in a manual fashion, either.)

Someone above posted this: https://github.com/google/python-fire

seems you could generate something with fire tool and then parse it dynamically with Gooey.

Makes sense, basically turns any CLI program into an API with the simple translation interface being the unix shell textual interface via simple JSON files which contain the commands.

I'd love to see a new python type annotation based tool that could decorate a function and let you expose it as a CLI, a GUI or a REST/GraphQL API (maybe even an html form).

pretty much a combination of Gooey, click and FastAPI

You might be interested in this, though it doesn't cover GUI stuff afaik:

https://github.com/hugapi/hug

I have been using yad based on gtk (https://sourceforge.net/projects/yad-dialog/) for some shell scripts and wrappers to external tools.

It's using the wxWidgets library for the heavy lifting, so should be fast and have native feel on multiple platforms.

Very cool, going to try this out for some of our internal toolkits. Easier than reading the help files for newbies, still has CLI for automating.

This is nice. But I have long since abandoned argparse in favour of click. And most 'serious' cli apps use click in my experience. Having click support would make this very interesting for many of my work projects.

Gooey could use a GUI that generates the Gooey config at the press of a button.

Gooey is nice, it could help in a wish I have had since foreveR and is the contrapositive: a way to convert any action I do on my Xubuntu UI into a command line.

Example: I pop the display config, hide the laptop screen, apply and confirm, and whish there was a "log" somewhere with a one line command I can use next time to redo the same thing.

In a way Gooey, if used a lot to make GUI apps, could help fullfilling this whish: I did not use it yet but I hope it displays somewhere the command line it generated from the GUI?

For your concrete example of display configuration, I think `xrandr` is the command you're looking for.

It seems like almost a drop-in replacement for the widely used `argparse` standard library. Strange that there is no mention of this.

That's because it IS a drop-in replacement for Argparse

Gooey began its life as a monkey-patch of argparse. GooeyParser came along later to extend the limited argparse API with additional options that made specifying more complex GUIs possible.

I opted to leave that detail out of this one as I was trying to focus on the larger general capabilities, rather than the Python specific implementation details.

I would include it, at least as a footnote/sidebar! It will be a huge selling point for python projects that already use argparse, and there are a lot.

Good idea. I'll do a quick update!

Is there a repository of Gooeys people have made?

Something like this for the web would be awesome. Maybe closely tied with something like FastAPI.

I ran into https://github.com/wooey/Wooey when I first ran into Gooey (years ago) and had the same thought.

From the link:

gooey_options={ # NEW! 'validator': { 'test': 'user_input.isdigit()', 'message': 'Please enter a number' } })

'test': 'user_input.isdigit()',

'user_input.isdigit()'

'o'

Finally, now people can make a GUI for git if they need one.

Yes, this is exactly what i'll use it for.

No CLI app is being robbed of anything, this is a layer over the top.

GUIs are very valuable because they can do things CLIs cannot, like show you at a glance what operations are available, promote the standard usecase of the CLI etc. Stuff that takes a bit of reading and clever typing with a CLI.

This tool allows you to quickly write a highly specific GUI that is using CLI app in the background.

> like show you at a glance what operations are available, promote the standard usecase of the CLI etc.

I definitely agree with this. I think getting people up to speed on how to use a CLI tool would be a great use case for this.

I would probably use more cli tools if there was a clear GUI introduction that shows how the options map to the commands.

If the textual interface is hidden, you at least lose scriptability, aka the (near) sufficiency of performative skill in a task to automate that task.

Not a downer at all! You're absolutely right that you lose power by strapping a GUI onto a CLI. In Gooey's case, that loss of power is actually the point! :)

This is something that's called out in the main Gooey documentation, but omitted in this this guide: Gooey is made to solve the problem of getting usable software to non-techie people's hands without having to write layers of GUI code or change how we'd write software. The main idea that spawned Gooey was that it could act as an "impedance matcher" of sorts between how I want to write software as a developer (CLI), versus how end-users want to consume software (GUI).

This exactly. Just being able to throw a quick interface at a powerful CLI would save the day for your excel-lover boss, or your mom. And save you hours of searching a bad-but-with-GUI alternative

Even as a software developer I find many CLIs annoying. People say to read the man pages, but I don't want to waste that much time. In some cases, I much prefer having a simple tool that hand holds me and tells me what to do.

Of course, for scripting and automation you need non-CLIs. And a lot of the time it is faster to use a cli tool, but, for the niche tool that I don't use that much (like mpv or curl), a simple GUI is nice.

Any screenshots of what it does with stderr?

Sure. Check this out: https://imgur.com/a/2TNi8SZ

It displays on the main screen and pops a modal.

Edit: pops a modal if the return code is non-zero, that is. If its just piping stuff over stderr as part of its normal run, it will be logged to the screen like normal stdout.

Thanks...seems like a reasonable approach.

Sounds exactly like the tool for spinning out quick mockups I was in need of.

I've always thought that a natural 'friend library' for libargs or libopts could be produced which parses the args and creates a dynamic gui from it .. but now I look at this and wonder, why hasn't someone done this already? It seems like obvious low-hanging fruit ..