brick icon indicating copy to clipboard operation
brick copied to clipboard

Progress bar usage

Open khazaddum opened this issue 9 months ago • 5 comments

Hello,

I'm trying to implement a progress bar that increases as a list is traversed, not based on user input. Are there any examples?

The issue I'm running into is that the UI doesn't redraw until the entire function traversing the list returns, the function updates the state field for the bar's value on each iteration but it doesn't redraw the UI.

I tried using a BChan to produce an event on each iteration but that produced this: thread blocked indefinitely in an STM transaction.

Any guidance would be very appreciated.

khazaddum avatar Apr 28 '24 12:04 khazaddum

a progress bar that increases as a list is traversed

Can you say a bit more about what you mean by "traversed"?

Do you have an application repository that I could look at, to see what you are trying to accomplish?

I tried using a BChan to produce an event on each iteration but that produced this: thread blocked indefinitely in an STM transaction.

This error is not inherent to using a BChan; it would be triggered by something about the way your thread interactions are working. If I could see your code, that might allow me to spot the issue.

jtdaugherty avatar Apr 28 '24 17:04 jtdaugherty

I have a processBlock function that processes a list item and updates the state with the value for the progress bar. I'm mapping this function over a list, but the UI doesn't redraw until the entire call to map in the event handler finishes, so the progress bar just jumps from 0 to 100.

I tried using a BChan to try to trigger an internal event:

          eventChan <- BC.newBChan 10
          let buildVty = VC.mkVty V.defaultConfig
          initialVty <- buildVty
          void $
            M.customMain initialVty buildVty (Just eventChan) theApp $
            State
              ...
              eventChan

I figured the easiest way to make the BChan available to the event handler would be to put it in the state. Inside the processBlock function, I write an event to the channel, but it produced that "thread blocked" error. Maybe my function is exceeding the 10 event limit?

After thinking about it today, I think it might be possible to get the effect by using the event handler loop itself to iterate over the list, but I think that would still require an internal event, otherwise the user would need to press a key to advance every tick.

khazaddum avatar Apr 28 '24 21:04 khazaddum

I figured the easiest way to make the BChan available to the event handler would be to put it in the state.

To confirm, this is indeed a common way to do it.

Inside the processBlock function, I write an event to the channel, but it produced that "thread blocked" error.

If processBlock is called from within an event handler, that would probably trigger this: the same thread that is doing the reading is also doing the writing. The BChan should be written to by a background thread that is doing the work.

I think it might be possible to get the effect by using the event handler loop itself to iterate over the list, but I think that would still require an internal event

Yes, that's right. You'll need to make your own custom event type, and give it a constructor like ListProgress .... Then add a handler for that event that updates your state's progress bar. Provided the ListProgress events are coming in at some slow enough interval, then you'll end up with interesting UI behavior. Granted, if you're just wanting to do work you're already doing with map, then that's likely to be so fast that a custom event won't help you because the progress bar will just go to 100 percent quickly; the assumption that would make it possible to do what you want is that the work actually does take long enough that you have incremental progress to report, i.e., a "tick" equivalent.

jtdaugherty avatar Apr 29 '24 00:04 jtdaugherty

For what it's worth, when I've done something like what you're doing, I have a thread that has a TChan for taking requests from the event handler, and a BChan for sending "responses" back to it in the form of custom events. So I end up with:

  • A data type like Request that I use to tell the worker thread to do some work over a TChan,
  • A custom event type that the worker thread uses to communicate a "response" over a BChan,
  • An event handler case to handle my custom events from the worker thread,
  • One or more event handlers that cause work requests to be made to the worker thread over its TChan, and
  • A bit of code to spawn the worker thread before calling customMain or whatever brick entry point is being used.

jtdaugherty avatar Apr 29 '24 00:04 jtdaugherty

@khazaddum let me know if there's anything else you need before we can close this.

jtdaugherty avatar May 01 '24 04:05 jtdaugherty

I'll close this since I assume you have what you need, but feel free to open another issue if you need assistance.

jtdaugherty avatar Jun 03 '24 02:06 jtdaugherty