Add --ignore-gooey option to README

[jrjhealey]

Hi!

Not a bug so much as an oversight in the readme perhaps?

I spent quite a long time agonising about how to make a CLI interface and a GUI option play nicely together. I knew there had to be an elegant solution somewhere (such as switching between framework/non-framework python.

I noticed in the STDOUT while the program ran however, that it spits out a verbose version of the full call to python which highlighted the --ignore-gooey option which suffices for this perfectly - but there is no mention of this in the README, or any docs I could find.

Could I suggest/request this be highlighted somewhere (and perhaps a more full guide with it if there are other things to consider when using --ignore-gooey that I'm not aware of).

Otherwise, love the package!

Joe

[elad-eyal]

1. In Windows I was able to use sys.stdout.isatty().

import sys
def prompt_for_one_of(prompt_text, *args):
    if sys.stdout.isatty():
        while True:
            print(prompt_text)
            for i,s in enumerate(args): print(f'{i+1}. {s}')
            i=input()
            try:
                return args[int(i)-1]
            except:
                pass
        
    else:
        import PySimpleGUI as sg 
        window=sg.Window(Path(__file__).stem,
                         [ [sg.Text(prompt_text)],
                           [sg.Button(t) for t in args] ])
        event, values = window.Read()
        window.Close()
        return event

response=prompt_for_one_of('Would you like to save?', 'Yes', 'No')

2. I also have this, so if you run my app with no parameters you get the GUI, but if you run in with any parameters you can the CLI version; so this is backwards compatible with the tool before gooey

    if len(sys.argv)>=2:
        if not '--ignore-gooey' in sys.argv:
            sys.argv.append('--ignore-gooey')

[chriskiehl]

Hey @jrjhealey,

Yeah, --ignore-gooey was originally intended as an internal implementation detail. However, people have independently discovered it several times over trying to accomplish exactly what you're after. So, maybe it is time to actually document it ^_^

I've been slowly updating README and docs/ on the release branch. I've updated your issue title and will make sure it goes into the next release!

Out of curiosity, are there any other pieces of Gooey you feel are under documented?

Thanks!

[jrjhealey]

That’d be perfect thanks Chris!

I’ve barely dipped my toe in the water, but the only other things I’ve noticeably struggled with whilst using Gooey so far have been (just off the top of my head, and I realise these aren’t necessarily undocumented aspects per se):

• I think some of the widget choices are still undocumented? Or at least, what widget choices all the normal argparse actions will map to. I know the docs say that by-and-large, sensible widgets will be chosen for each action, it might be good to have a full mapping for this. In particular, I've noticed the count option which should employ a drop down, behaves weirdly when expecting an int.

• More documentation for the customisation of the GUI window might be useful, in my testing, I wasn’t able to get several of the colour options to take effect, only the header would ever change colour. Perhaps this is a bug, or perhaps there’s more to it than I’ve realised/the documentation lets on?

• The last thing is packaging for MacOS which I still haven’t cracked yet, but I realise this is an active issue in other threads, so is probably more than a documentation issue.

[zertrin]

I also have this, so if you run my app with no parameters you get the GUI, but if you run in with any parameters you can the CLI version; so this is backwards compatible with the tool before gooey

    if len(sys.argv)>=2:
        if not '--ignore-gooey' in sys.argv:
            sys.argv.append('--ignore-gooey')

This is exactly what I needed (only start Gooey if the script is started without argument, otherwise operate as CLI). It is very simple and straightforward, however there is a caveat that took me some time to understand:

⚠️ you need to place the code before the @Gooey() decorator.

So for example, you can do like this:

import sys
from gooey import Gooey, GooeyParser
# other imports...

# this needs to be *before* the @Gooey decorator!
# (this code allows to only use Gooey when no arguments are passed to the script)
if len(sys.argv) >= 2:
    if not '--ignore-gooey' in sys.argv:
        sys.argv.append('--ignore-gooey')

@Gooey(options=...)
def main():
    parser = ....
    # rest of your code


if __name__ == '__main__':
    main()

Initially I tried putting it in the if __name__ == '__main__' section, but that won't work.

if __name__ == '__main__':
    # this does NOT work, it is executed too late
    if len(sys.argv) >= 2:
        if not '--ignore-gooey' in sys.argv:
            sys.argv.append('--ignore-gooey')
    main()

[chriskiehl]

@ jrjhealey regarding your point on OSX packaging, would you mind giving the new packaging docs a whirl?

[jrjhealey]

Will give it a try ASAP :)

Just FYI, I'm getting 404s on both of the links to the template .spec files at the moment (but this could be me as I'm currently on a crap internet connection).

[zertrin]

@jrjhealey if you get 404 it means your Internet connection is fine. That means the server didn't find the resources. Not your fault.

[bradh11]

@zertrin your solution is brilliant and is exactly what we were looking for regarding a recent project we are working on. I’m wondering if there is an even more elegant way to somehow add a Boolean option into the decorator to toggle Gooey UI on or off depending on arbitrary logic determined in the code. For example listen for -ui in sys.argv and have that be the trigger to enable Gooey. I haven’t looked at the source code yet, but it seems this should be possible.

I do also think the use case to fallback to ui or give the user a choice is definitely something that should be fully implemented and in the docs too. Our use case for example was a distributable app for on demand usage (GUI) that we might also want to use for cron jobs (CLI).

[rowlesmr]

@zertrin @eladeyal-intel Your solution for no arguments == GUI, arguments == CLI just helped me immensely.

Can this be an option in the Gooey decorator?

[spookylukey]

One of the issues with the above solution is that if you are using just the CLI, then you are still doing import gooey, which can take a measurable amount of time, and is unnecessary.

Instead, you can do this, which avoids the import if not needed:

# Normal main function without Gooey decorator.
def main(): 
    # etc.


if not sys.stdout.isatty():
    # If we are not attached to a terminal, use Gooey
    from gooey import Gooey
    main = Gooey(main)

    # or:
    # main = Gooey(options=...)(main)

# otherwise, simply don't import or use Gooey at all

if __name__ == '__main__':
    main()

In main = Gooey(main) we are just using the longhand way of using a decorator.

[makew0rld]

It'd be nice if Gooey moved away from --ignore-gooey (but still left it in) and just did this by default, configurable by the an argument to the decorator.

[ed2050]

Three years later, a bunch of comments, and still no fix. --ignore-gooey is still undocumented. The readme still gives no indication of how to run both cli and gui versions, which is a basic requirement for such programs.

Worst of all, the key and completely counterintuitive info that --ignore-gooey must be placed in sys.argv BEFORE the @Gooey decorator (why?) is still buried in zertrin's comment in the middle of this obscure hidden page.

Do the developers even run command line programs?? It seems they don't care at all about preserving & documenting basic functionality that's been standard behavior since the 1970s.

Overall nice project, great work. It's like you built a fabulous luxury car... and then forgot to install a gas tank.

[skeenp]

For anyone interested, I came across this same issue and have shared my solution as a wrapper to Gooey. skeenp/gooeywrapper based on my own experiences and information in this thread.

I needed a reusable wrapper for the platform for a stack of GUIs across a number of projects. The wrapper handles using argparse when in CLI mode, Gooey when in GUI mode and also detects if running in CLI mode in the interactive window of the GUI.

The main thing this does that adds to the information in this thread is to address the different options add_arguments supports between argparse and Gooey. For example, argparse raises an error if it gets passed 'widget'. This has meant that it was difficult to reuse the code.

[corlanmcd]

@skeenp Man, I can't thank you enough. I just sumbled upon Gooey yesterday and thus this same scenario. ~~I do have one question, how is one to add/modify the "@Gooey" decorator using the gooeywrapper?~~ EDIT: This is done by passing the respective configuration parameter through the argument of the Gooey function within the wrapper (Line 55).