FR - Running EXE asks for options about jamstats HOT 18 CLOSED

I'll try to do this the "easy" way with Gooey, though that'll add more library dependencies to the project (and make the .EXE bigger and maybe slower). If Gooey doesn't do it for me I'll build something with tkinter.

First attempt will be bare-bones. If people start using it and are clamoring for more (e.g., color dropdowns for the teams) those can be separate FRs.

from jamstats.

Oh, one question, @bullseye555 : for this to be useful to people, do you think the GUI needs to be the default behavior if the .EXE is double-clicked? Or would it still be useful if they had to go to the commandline and type "jamstats.EXE --gui"?

I ask because making it the default behavior will break the usual Unix/Mac commandline expected behavior of "run it with no arguments to get the usage docstring".

from jamstats.

(note to self) This stackoverflow solution should be helpful:
https://stackoverflow.com/questions/56580102/clever-ways-of-switching-between-gui-and-cli-modes-with-gooey

from jamstats.

OK, I added the GUI for argument capture. You get it if you run the thing with no arguments (or, presumably, if you just double-click the EXE in Windows). It looks like this:

Upside: I think it looks fantastic (YMMV, and I'm open to suggestions for tweaks, mostly on the help language)

Downside: it depends on the "gooey" package, which depends on wxpython, which took forever to install in my Python installation. So, I'm worried it'll bulk up the executable and make it slow. @bullseye555 , please test it out and let me know how it goes. You can download the executable with the gui (zipped) here.

from jamstats.

I realize that typing or cut-pasting in the input filename is difficult, maybe nearly as difficult as running the tool from the commandline. One reason I did it that way is that I wanted to preserve the drag-and-drop interface. For that to work, jamstats has to be able to accept a single argument that is (or can be) a file. That's why I overloaded the single argument to be either a file or a port number.

I can't think of a good way around that -- that is, to make the input file argument be of a "file" type, so that the gui would give you a file chooser. I could make multiple executables (one for JSON files and one for the webserver)... that's more work and more for people to manage. I could have a "--webserver" argument that would switch the behavior... but then you'd still need to input a filename as the first argument, which wouldn't make any sense.

Do you think having to supply that file argument through the text box will be a deal-breaker for people who would want to use this GUI?

from jamstats.

The other option is to give up the drag-and-drop interface. Then I could let the user use a file chooser if reading a json file or specify a server and port if connecting to a webserver.

How important do you think the drag-and-drop is?

from jamstats.

In answer to your questions: (I'm about to download the file you linked and have a play with it, so this is before I've used it)

for this to be useful to people, do you think the GUI needs to be the default behavior if the .EXE is double-clicked? Or would it still be useful if they had to go to the commandline and type "jamstats.EXE --gui"?
I think having it has default behaviour when double clicking the EXE would be the expected behaviour [In the same way that just double clicking the CRG Scoreboard.exe file just runs CRG, but you can still run via CMD with parameters

Do you think having to supply that file argument through the text box will be a deal-breaker for people who would want to use this GUI?
I think it's more user friendly, and is definitely going to be adopted quicker if the GUI interface in more intuitive - having said that

The other option is to give up the drag-and-drop interface. Then I could let the user use a file chooser if reading a json file or specify a server and port if connecting to a webserver.
How important do you think the drag-and-drop is?
I think having the file chooser over drag-and-drop would be more user friendly - especially if the drag-and-drop means having to manually enter the file location

from jamstats.

@dhmay - Error running the EXE

Same error in both Win Server 2019 64bit (screenshot above) and Windows 11 64bit.

Server doesn't have python installed, but Win11 machine does. Going to install gooey and wxpython and see if that helps

from jamstats.

Shoot! Sorry, I'll debug over the weekend.

from jamstats.

All good

Confirming same error after installing wxpython and gooey

I'm sure it'd work if running from source instead of via the exe

from jamstats.

Hm, I might have fixed it here:
https://github.com/dhmay/jamstats/suites/10233483509/artifacts/501729428

But I need to verify on a windows box.

from jamstats.

It starts, yay!

But it fails to run :(

from jamstats.

It does work via CMD though

from jamstats.

OK, this time I think I got it. I changed the usage as you suggested -- there are now two options for the input argument and two for the output argument, and that allows you to use file choosers if the input or output is a file. Since there's no longer a single argument for input, drag-and-drop will no longer work.

https://github.com/dhmay/jamstats/suites/10233856743/artifacts/501757390

I'm getting some weird behavior with the input file chooser, with it warning me that it was going to save over the file (even though it was opening it read-only). I'll dig into that. That was on a mac, though, and I'm curious whether you get the same on Windows.

from jamstats.

(if you do get that scary overwrite warning you can just click through it to open the file properly)

from jamstats.

Confirming GUI opens and runs (see #76 for WebServer plotting bugs)

Also confirming that I do get the Confirm Save As dialogue box after selecting the file

It looks like the Browse window is opening a Save / Save As dialogue instead of an Open File dialogue, which is why it's throwing the prompt - the OS recognises the file exists, see's that it's a Save dialogue so throws the This file already exists warning

from jamstats.

Fixed!

from jamstats.

Confirmed working on a Windows box, too

from jamstats.