-
-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PyApp with GUI program - disable console on Windows #96
Comments
It's been a while since I used pyapp and I might be wrong on a few comments, but I have some questions/worries: IIRC if we open two processed of pyapp and the venv installation wasn't finished, one or both will fail. I had to run Is there a mechanism to automatically run the self restore command on installation or imports failure, and could this be an issue when a user clicks the app, it takes a while to load/install and they spawn many processes of it? ~ For that, it's probably feature creep, but a quick pyinstaller-like splash screen would be nice to have- -or even detecting same-name processes of the pyapp binary already running and giving preference to the older one* *This might NOOP and require task managers strategy of sending a challenge signal to the process we might replace to detect if softlocked or healthy |
I agree with your worries. These started to come up when I was testing the implementation as well. There's a longer explanation / write up in the PR, see #97. The short is:
|
about subsystem = "windows" |
Resolved by #97 |
When running PyApp packaged GUI on Windows, a console window is generally open which is not really the wanted behavior. This is not the case on Linux, don't know right how it is on macos...
In order run a GUI without a console windows on Windows, two things would be required as far as I can see it:
#![windows_subsystem = "windows"]
tomain.rs
, see RFC 1665pythonw.exe
instead ofpython.exe
when running.For 1 I currently don't see a good way of using an environmental variable. One possible solution would be to add
to
Cargo.toml
. This way, thewindows_subsystem = "windows"
top-level crate attribute could simply be activated during compilation withcargo build --features gui
.I'll prepare a draft PR that implements this, plus the
pythonw.exe
usage for running the program. Let me know what you think, this is just an idea at this point... the additions in the PR should make it easier to see hopefully.The text was updated successfully, but these errors were encountered: