Using Gooey as a Universal Front End for Any Language or CLI Application
chriskiehl.com
chriskiehl.com
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.
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.
It never worked perfect, but was "good enough" for the few simple things I needed it for.
[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...
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.
http://preserve.mactech.com/articles/mactech/Vol.06/06.07/Co...
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).
Commando was also part of A/UX. Here's a screenshot of Commando for the "ls" command: http://toastytech.com/guis/auxcmdo-ls.png
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!
If you're interested, do you want to open a feature request here? https://github.com/chriskiehl/Gooey/issues
"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."
> 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...
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?
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
CLI apps are already very programmable. How would you API-ify them even more?
system('yourapp --option1 --option2=something')(personally, I think it is, and helps give structure to the sometimes too "dynamic" world that is shell scripting)
Starting a subprocess via shell is could in particular be solved by a simple API of the form of:
system('yourapp', ['option1', {'option2' : 'something'}]);
pipe(system('yourapp', ['option1', {'option2' : 'something'}]),
system('grep', ['n', 'i', 'foobar']),
system('somethingelse', [], null, file("/dev/null")));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())
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.
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.
Perhaps the probing could happen in a VM / container image which would reset after each invocation.
seems you could generate something with fire tool and then parse it dynamically with Gooey.
pretty much a combination of Gooey, click and FastAPI
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.
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?
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.
gooey_options={ # NEW! 'validator': { 'test': 'user_input.isdigit()', 'message': 'Please enter a number' } })
'test': 'user_input.isdigit()',
'user_input.isdigit()'
'o'
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.
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.
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).
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.
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.