Launching runviewer briefly opens a million windows on Windows 10

[philipstarkey]

When launching runviewer from runmanager on Windows 10, I'm getting a million windows very briefly showing up one by one. Basically I see a lot of flashes on my main desktop and in the taskbar. They continue even after the splash screen for runviewer has appeared.

This appears to be due to the use of the DETACHED_PROCESS creation flag in combination with launching runviewer with python -m runviewer. I have replicated it by launching a subprocess via an interactive Python terminal so it is not caused by anything else happening in runmanager.

Once solution is to launch runviewer from runmanager using ['runviewer-gui'] rather than [sys.executable, '-m', 'runviewer'] but I'm not entirely certain if that executable is always in the path or not (it is for my dev install on conda).

[chrisjbillington]

I'll look into it. It's probably true that DETACHED_PROCESS is causing the problem - otherwise runviewer would just inherit the (hidden) console window of runmanager. Unsure why we have not seen this problem prior to the restructuring though. I was going to suggest it might be an issue specific to virtual environments since they have this extra layer of processes every time you launch a subprocess (which I suspect will cause us issues and I'm going to modify zprocess to avoid it in the same way that the multiprocessing module does - though this is not strictly relevant since runviewer isn't launched via zprocess), but sounds like you're using conda.

Probably just need to add the HIDDEN_WINDOW flag or whatever it's called to Popen call.

[philipstarkey]

Isn't it odd that it doesn't do it if you call the entry point directly though? Is there a reason why we shouldn't switch it to using that?
is subprocess.Popen(['runviewer'], ...) cross platform?

[chrisjbillington]

I'd rather not rely on PATH as I see it frequently misconfigured (e.g. ~/.local/bin is not even in the PATH on Ubuntu, neither is the equivalent on Windows - for me, I hear it is for others), so if I were to do that I'd want to look up the scripts directory for the current Python environment and use it to provide the full path (desktop-app has a function to find the scripts directory given the location of a particular module, since it's kind of nontrivial given all the possibilities for where it can be). Even that is IMHO less preferable to the import system, though one argument in favour of using the launcher script is that the launcher script is how humans launch it, so the automated launching should then be identical to human-initiated launching in all cases including anything unanticipated.

It's not strange that runviewer-gui doesn't have the problem, since the launcher jumps through some hoops to make sure this is the case (with no extra windows popping up, I worked hard to make that happen :p). However, those hoops do not generally need to be jumped through for further subprocesses and only are here because of the DETACHED_PROCESS.

Sorry, I haven't looked into this yet, but I'm sure it's an easy fix. I'll probably just have the Popen call call runviewer-gui, though that means using the desktop-app function to find the scripts directory, which I hadn't considered part of its public API so far (not that it's documented yet what is and what isn't). But I'll probably just go ahead with that.

[philipstarkey]

It's not strange that runviewer-gui doesn't have the problem

To be clear runviewer (without the -gui also doesn't have the problem)

[chrisjbillington]

To be clear runviewer (without the -gui also doesn't have the problem)

Ah I guess that's unexpected, I thought there would be one. The initial launcher process should not have a console window because of DETACHED_PROCESS, but then its child process (the actual runviewer process) I would have expected to have a persistent console window the same as if you double-click a .py file when associated with Python.exe.

I'm not going to bother trying to understand exactly, it doesn't really matter. But I gotta go to bed so will fix this tomorrow...

[philipstarkey]

Fixed in #95