Skip to content
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

Closed
trappitsch opened this issue Mar 11, 2024 · 4 comments
Closed

PyApp with GUI program - disable console on Windows #96

trappitsch opened this issue Mar 11, 2024 · 4 comments

Comments

@trappitsch
Copy link
Contributor

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:

  1. Add top-level crate attribute #![windows_subsystem = "windows"] to main.rs, see RFC 1665
  2. Execute the program with pythonw.exe instead of python.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

[features]

gui = []

to Cargo.toml. This way, the windows_subsystem = "windows" top-level crate attribute could simply be activated during compilation with cargo 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.

@trappitsch trappitsch mentioned this issue Mar 11, 2024
6 tasks
@Tremeschin
Copy link

Tremeschin commented Mar 14, 2024

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 app.exe self restore command on a terminal to start fresh (or even manually delete the virtualenv folder)

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

@trappitsch
Copy link
Contributor Author

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:

  • targeting windows_subsystem = "windows" for PyApp is not a good idea, since setup, management, etc. require the console.
  • GUIs can be run in the run_project with pythonw.exe. A console appears now briefly when starting the app but then disappears. I think that's a fair trade of. This also means that all the great things with PyApp stay, like installation splash screen, self management from the console, etc.

@shenjackyuanjie
Copy link

about subsystem = "windows"
I have a rust project about a caller wrapper in rust
it may can help you doing it

https://github.com/shenjackyuanjie/wrapper-rs

@ofek
Copy link
Owner

ofek commented Mar 24, 2024

Resolved by #97

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants