search

labscript-suite / runmanager

𝗿𝘂𝗻𝗺𝗮𝗻𝗮𝗴𝗲𝗿 is an intuitive graphical interface for controlling 𝘭𝘢𝘣𝘴𝘤𝘳𝘪𝘱𝘵 𝘴𝘶𝘪𝘵𝘦 experiments. Includes multi-dimensional parameter scans and a remote programming interface for automation.
http://labscriptsuite.org
Other
3 stars 45 forks source link

Launching runviewer briefly opens a million windows on Windows 10 #92

Closed philipstarkey closed 4 years ago

philipstarkey commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Fixed in #95