brick
brick copied to clipboard
Progress bar usage
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.
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.
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.
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.
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 aTChan
, - 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.
@khazaddum let me know if there's anything else you need before we can close this.
I'll close this since I assume you have what you need, but feel free to open another issue if you need assistance.