Progress bar widget for long-running computations

[GenevieveBuckley]

Have you thought much about whether it might be possible to add a progress bar that updates with long-running computations?

Most of the current examples (snell's law, etc.) are fast by design but I imagine many real-word cases might be much slower, and it might be good for users to have some kind of indication that things are running. This might get complicated because you'd need analysis functions to have a way to communicate back to the magicgui dockable widget. I wanted to get your thoughts given the work you did on two way communication with threads in napari.

Relevant links:

• https://doc.qt.io/qt-5/qprogressbar.html

[jni]

Well, one issue is that many computations don't really provide this, and we want to support arbitrary computations. Dask does provide one, so it's probably doable to hook into it.

But if you're saying, provide a widget that you can write a computation specifically to hook into with progress... That should be doable I think?

Anyway, certainly would be interesting... 😬

[tlambert03]

I agree, that would be cool feature. But as @jni said, it's not clear how to achieve this in a generic way. We could create an API that a user could use (with generators and yields) that could do something like this, but i can't see my way to a solution without some degree of buy-in from the end-user (which might be fine). For a hot minute, there was the ProgressWorker example in napari/napari#1210, which is the kind of thing I would imagine is needed. but maybe we can think of a clean API to mimic the example progress bar in https://github.com/napari/napari/blob/master/examples/multithreading_two_way.py

[GenevieveBuckley]

But if you're saying, provide a widget that you can write a computation specifically to hook into with progress... That should be doable I think?

Yes, I mean that the user would be the one to make sure their computation hooks into an API for indicating progress.

[tlambert03]

With #104 and #105 in I'm going to close this. While we haven't implemented any sort of threading support, the tqdm progress bar works reasonably well in a single threaded system, since it calls app.processEvents() on each iteration. Threading can wait