I'm very much a command line guy but ffmpeg still stumps me. Might be nice if it could save the various ffmpeg arg soups as some kind of friendly name, e.g. "combine jpegs into a timelapse" or "convert video to HTML5-friendly format" and then just drop-down and fill in the timelapse parameters or whatever.
I don't use it myself, but maybe have a look at Staxrip? It's not quite that user friendly, but a lot more than remembering the commands for making a video from individual images.
I personally have no desire to use it outside of Windows, but Powershell fixes all there things if you're so inclined:
> 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.
I just have a folder with a bunch of scripts with various descriptive names which launch ffmpeg with different painstakingly composed argument chains. I could join them into a mega-script which would prompt me upon execution but I don't see the point in an additional indirection.
Sometimes one script is just not enough/not convenient enough, and I write simple helper wrappers such as:
If you want to see an example of that exact thing, I've got a small suite of wrapped FFMPEG tools doing exactly that via Gooey. Having things like screen recording, gif creation, trimming/truncating in a GUI just makes them way more convenient for my frail brain compared to FFMPEG's tough APIs.
Plenty of options, one I haven’t seen mentioned is Shutter Encoder. I don’t think it covers all of ffmpeg functionality, it focuses on format conversions useful for video professionals and does a fine job of it.
10 randomly sampled adults, nevermind parents. My partner is an educated person who works on a computer all day and I think she would have a panic attack if I asked her to do something on a command prompt
What are the tools my "non command line fluent parents" could/would want to use that don't already have a human crafted GUI ? This lib, as smart as I think it is, doesn't create "simplicity" from a void.
Never in the last two decades did I encountered a "parents" usage where any CLI tool were needed to do some work. Yes it did happen that I had to use them to repair things. But having auto-generated GUIs on these tools wouldn't change anything about the lack of understanding of what it is, why it's needed and what it does.
If we are talking about generating GUIs for complex production tools like ffmpeg, tar, git ... there already are plenty of wonderful and less wonderful frontends that a auto generated GUI could never beat.
But I'm not saying this tool is not nice. Just I think it's targeted at power users that don't want to open a terminal. It's not a lot, but it's something.
> GUIs for complex production tools like ffmpeg, tar, git ... there already are plenty of wonderful and less wonderful frontends that a auto generated GUI could never beat.
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 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.
This is the weirdest thing but I get a sort of "uncanny valley" effect from all the screenshots, I try to parse them as Installshield Wizards but they're actually regular apps.
I've used this to provide simple UIs to scripts for consulting projects where something more complex wasn't justified.
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.
Looks like Zenity/Xdialog for Python apps - these solutions work great within designed limits, and if your app is non-trivial you'll hit these limits sooner or later.
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.
If you like the look of fire for the ease of creating a cli but wish it automatically did validation based on type annotations, you might like Typer[0]. The pathlib parameters are especially handy, I find.
I also recommend checking out Clicky. It is similar to Fire, but has been out there for very long time and has some more power features and documentation.
Actually, I misspoke slightly when I said it turns the GUI into a CLI. Rather, it turns the same underlying class into a GUI.
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)
which takes care of all the CLI access we could want.
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 :
Seems like you have update your API in two locations when changes happen, once in the `JobManager` definition and another time in the parser. How do you avoid issues with inconsistency?
Oh damn, that's fantastic! I wanted to write a small server that did something between this and Fire above (i.e. allowed you to drop a Python script into a directory and would create a UI for its functions). It's a great way to make small, random functions I've written accessible to people with zero work.
Just found out about this, looks cool! Unfortunately file handling is a bit wonky, I suspect some of that is just the web platform (e.g. can't select directories), while some of it is probably due to a lack of bandwidth from what looks to mostly be a solo developer.
I've been using Gooey quite a lot lately and I'm really tired of setting up Argparse every time. Your recommendation of Fire came at exactly the right time! Thanks
In our setup, we have a class that does the heavy lifting. The file where that class lives ends with :
if __name__ == '__main__':
fire.Fire(JobManager)
which turns it into an instant CLI.
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.
I wonder if this + dependencies could be bundled into a golang binary with the new embed feature, then python could exec the bin or vice versa. I guess zenity would be better for that
Does it? I haven't been able to get it to work correctly with Fire.
@Gooey()
def main():
fire.Fire()
def hello(name="World"):
return "Hello %s!" % name
if __name__ == "__main__":
main()
It just runs Fire instead of launching Gooey. I've tried quite a few other things re: getting Fire to work with Gooey but nothing seems to have an effect
> Turn almost any Python command line program into a GUI application
Why would anybody need this? Xterm is already a GUI application and you can run the original program inside it. What benefit is there?
What I'd like is the inverse operation: turn an arbitrary GUI application into a command line program. Now, that would be really useful! That would allow a lot of automation that is difficult with GUI stuff. It seems a really, really hard problem though.
Yes, I read this, and it is essentially an aesthetic, UX issue. But it does not allow you to do things any easier in practice (at least if you are used to the command line). I was just asking it semi-rhetorically to introduce my question about the inverse transformation.
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.
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.
You can check out ConfigArgParse[0]. It allows you to use command line arguments, environment variables and config files to control the behavior of your scripts. I'm not sure if you can use it with gooey or not.
This is for Python, but I see much more potential for implementing this in Raku which has built-in support for strongly-typed command-line syntax defined as the signature of the MAIN function.
Does anyone have any experience on how this couples with nuitka, pyinstaller, py2exe?
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've been successful using PyInstaller to make executables out of PySide2 (Qt5) applications for Windows, Mac and Linux. (I probably should do a write up on that at some point). It's been quite a while since I touched Wxwidgets, but its packaging process should be similar and may result in smaller binaries if it's calling out to shared libraries (ie for the toolkit on Win).
I wish people would stop linking MrS0m30n3's GUI. It's no longer maintained and other fork(s) are active. The one which so far retains the look is called yt-dlg now.
You can actually use Gooey for any arbitrary program or language (if you don't mind configuring a few of your cli arguments in python). Gooey technically just uses Json behind the scenes, but Python remains the most first class way to generate that blob of json.
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]
So, it looks really cool, but it requires wxpython, which in turn seems to be an issue installing on Linux. Which, since I'm using Ubuntu 20.04 (not an exotic flavor of Linux) and python3, was surprising to me, but it appears to be a common issue (lots of blog posts saying lots of different ways to get around this). Might be useful to make some docs on how to install on the most common flavors of Linux? If this already exists, my apologies, I didn't see it.
115 comments
[ 4.4 ms ] story [ 199 ms ] thread> 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.
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...
[0]https://github.com/chriskiehl/GooeyVideo
https://www.shutterencoder.com/en/
Never in the last two decades did I encountered a "parents" usage where any CLI tool were needed to do some work. Yes it did happen that I had to use them to repair things. But having auto-generated GUIs on these tools wouldn't change anything about the lack of understanding of what it is, why it's needed and what it does.
If we are talking about generating GUIs for complex production tools like ffmpeg, tar, git ... there already are plenty of wonderful and less wonderful frontends that a auto generated GUI could never beat.
But I'm not saying this tool is not nice. Just I think it's targeted at power users that don't want to open a terminal. It's not a lot, but it's something.
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 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.
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.
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
which takes care of all the CLI access we could want.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 :
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.
Gooey works with Fire, though.
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.
Why would anybody need this? Xterm is already a GUI application and you can run the original program inside it. What benefit is there?
What I'd like is the inverse operation: turn an arbitrary GUI application into a command line program. Now, that would be really useful! That would allow a lot of automation that is difficult with GUI stuff. It seems a really, really hard problem though.
Because they have no experience using a terminal, entering commands and finding documentation
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:
and it created an image with a white diagonal band erased in white.https://en.wikipedia.org/wiki/AppleScript
most likely both Windows and macOS would have similar mechanisms for accessing their respective accessibility api
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".
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).
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.
[0] https://github.com/bw2/ConfigArgParse
https://github.com/theskumar/python-dotenv
I'm not even jealous.. kudos
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! ^_^
https://docs.raku.org/language/create-cli#sub_MAIN
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
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
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