[enh] Remove modal flag from installer dialog

[psobolewskiPhD]

Closes: #117

This has been something mildly irritating for a while, so I finally looked into it.
It turned out to be super simple?

With this change the installer is no longer modal, so you can click back to napari and do whatever while plugins are installing, which is particularly handy if you choose to install several.

[psobolewskiPhD]

@dalthviz would appreciate your thoughts on this, perhaps I'm overlooking something.

[dalthviz]

Hi there @psobolewskiPhD ! Gave a check to this and seems like is working as expected 👍

As a side note, regarding why the dialog was set as a modal, maybe at some point in the past the dialog needed to be like that to prevent people to somehow interrupt installations in progress? From a quick check seems like PR #42 could have helped with that? Before that PR, closing the dialog would cause its destruction. Now, when the dialog is closed, in reality it's just hidden so just a single instance is created per napari launch and that single instance is kept while napari is running so in progress installations can be tracked? 🤔

[psobolewskiPhD]

cc: @TimMonko @DragaDoncila what are y'alls thoughts on making the dialog not modal?

[TimMonko]

Now, when the dialog is closed, in reality it's just hidden so just a single instance is created per napari launch and that single instance is kept while napari is running so in progress installations can be tracked?

Quick driveby, this is good enough reason to remove the modal to me.
But what happens if napari is closed during install? Say I x out the plugin manager, could I brick my environment by closing napari? One nice thing about the modal as it currently stands is that it says "hey something important is probably happening right now, I wouldn't try to do other things". Can we add a warning popup on close attempt if plugin downloads are in progress, perhaps?

[jaimergp]

But what happens if napari is closed during install?

This is my concern too. I remember Gonzalo bringing this up. I think we were supposed to add a progress tracker in napari so the plugin manager could submit the ongoing tasks. This is still not merged:

• Add utility function to query the plugin status from napari side #56
• Add a process status manager for plugins and napari processes napari#6993

I would consider those blockers for this PR to land.

[jaimergp]

@dalthviz can you take over the aforementioned PRs? 🙏

[psobolewskiPhD]

But what happens if napari is closed during install? Say I x out the plugin manager, could I brick my environment by closing napari?

How is this different from the current situation? You can close napari with the manager open -- try it! It takes priority!
The change here just lets you move a different window to the foreground, so the manager need not dominate focus.
You will still get warned to restart napari, etc.

[TimMonko]

What do you mean about being able to close napari with the manager open? For me, the modal nature completely blocks interaction with the napari interface, to be able to close. I also can't close napari by "normal" windows operations like from the task bar and such, it will be blocked. I can ctrl+w close napari without issue though (makes sense I guess)

If I close the manager during install and then also napari, I get this error:

WARNING: QProcess: Destroyed while process ("C:\\Users\\Tim\\napari\\.venv\\Scripts\\python.exe") is still running.
20:20:22 : WARNING : MainThread : QProcess: Destroyed while process ("C:\\Users\\Tim\\napari\\.venv\\Scripts\\python.exe") is still running

It seems after many times in testing this behavior and trying to install a plugin, I haven't bricked my environment, to my surprise.
Maybe there are safeties on the pip and conda side that prevent it? I'll even close during the "installing packages" status message, and not just the downloads so 🤷

[psobolewskiPhD]

I can quit with no issue 🤷
But I also get a message like that when just using the manager? I will try to test more tomorrow.

Edit: my understanding was that installation is done outside napari--sub process?--so closing manager shouldn't matter. But this is from my phone so 🤷

[jaimergp]

Yes, both pip and conda are run in a separate subprocess via the QProcess interface. So far we are operating in standard "child process" mode (the subprocess exits¹ if the parent exits), but we could also operate in "daemon mode" (the subprocess can outlive the parent). That might complicate the mental model a bit, and we would have to monitor for zombies.

Footnotes

1. The same exit signal is propagated to the children, which are then responsible for handling it gracefully. In the case of conda receiving a Ctrl+C event, this might happen mid-big-transaction, which needs to be rolled back, adding unnecessary delays to the exit of the program. This might annoy users if the need to wait is not communicated. These users might choose to force exit and then problems start. ↩

[psobolewskiPhD]

So is the thought that running installations should warn when trying to quit napari? (again regardless the decision on this PR, right now you can quit napari with the installer open/running)

[jaimergp]

Exactly, hopefully to be addressed with the two PRs mentioned in #166 (comment)