Is it possible to add FRP animations and reactive values to brick?

[amano-kenji]

1. https://hackage.haskell.org/package/keera-hails-reactivevalues-0.8.0/docs/Data-ReactiveValue.html says

Reactive Values (RVs) are typed mutable variables with a change notification mechanism. They are defined by providing a way to read the value, a way to change it, and a way to install an react when the value has changed.

RVs are abstract (i.e., a type class). This module defines a class and manipulation operations, but you need an actual instance of RV underneath. For a way to turn IORefs into RVs, see the example below. GUI toolkits can use existing event-handling mechanisms to make widget attributes Reactive Values without additional boilerplate.

It seems I can plug reactive value change notifications as customized application events through BChan. This is great for interactive UIs.

2. Can I plug a functional reactive programming libary into brick? Can I plug it into EventM? Or, brick is not compatible with FRP? FRP is not great for interactive UIs, but it's great for animations. Think ASCII or sixel animations. It can handle showing gif animations on terminal emulators through sixel. I don't think brick was designed to handle real-time animations. I don't need animations, but it's good to know whether it's possible with brick.

[jtdaugherty]

I don't know. Some people have tried it before, but I think they ended up forking brick to get access to some of the internals. I don't know enough about FRP to know whether it's possible to integrate with brick, but if someone wanted to try, I'd be happy to work with them on any issues that come up. I can't promise that it would work, though, because I just don't know whether FRP integration would mean changing brick's architecture, and there are probably limits to how much I'd be willing to change it to support FRP if the two types of systems are very different.

[amano-kenji]

My guess is that FRP code can run in a separate thread and pass the values that come out of the FRP loop to EventM through BChan. For example, gif animation frame number can change every 20 milliseconds. I don't know whether brick can handle it performance-wise without eating a CPU core.

[jtdaugherty]

I don't know either. Although I figure that if that's the kind of application someone really wants to write, the terminal is already not the best choice for that for a whole lot of reasons.

[amano-kenji]

My intuition tells me brick event handler won't be the performance bottleneck. Rendering one sixel frame every 33 milliseconds(30 frames per second) will eat a lot more CPU than handling a frame change event in EventM every 33 milliseconds. So, if I want to show one gif animation in terminal file manager's image preview, I probably need to optimize sixel rendering instead of EventM. And, for just changing gif anmation frame, FRP is an overkill. I guess FRP should be reserved for complex animations used in games or web browsers.

Does brick try to update only the changed parts? If so, then I think brick is optimized enough.

[jtdaugherty]

Does brick try to update only the changed parts? If so, then I think brick is optimized enough.

vty does, yes.

[amano-kenji]

If I combine vty with cached, then I may get efficient rendering for a file manager. I think we learned an important lesson here.

1. FRP is an overkill for simple animations that will ever be on brick applications. I may still use it in a separate thread for simple ASCII animations.
2. Reactive values can integrate with brick. I don't know how it is done, but I know it should be possible.
3. Brick seems ready for the next few decades. With reactive values, it is at the cutting edge of UI paradigms. I just need to develop an efficient sixel renderer in haskell if I ever want images in brick applications.

[jtdaugherty]

@amano-kenji I just found this, perhaps it would be of interest to you: https://hackage.haskell.org/package/dyna-brick

[amano-kenji]

According to https://github.com/ivanperez-keera, FRP complicates things when two GUI widgets bidirectionally influence each other's value. Bidirectional data flow complicates FRP. Thus, FRP is not still great for intereactive UIs. It is great for actuating animations.

The cutting edge he developed is https://github.com/ivanperez-keera/dunai which enables reactive values and FRP with one framework. Reactive values for interactive UIs. FRP for animations. There should be more research before FRP becomes suitable for interactive UIs.

Even now, you can use FRP in another thread to push animated frames to brick via BChan, but managing such threads can introduce mistakes if you are not careful.

If brick incorporated dunai and image protocols like sixel, it would be a super engine for terminal UI applications.

If there is a framework in brick for managing animation threads, then you may be able to actuate animations seamlessly.

[amano-kenji]

When I write an application, I will try mixing dunai with brick and tell you the result at the end.

I may see an opportunity to add a dunai layer on top of brick in order to provide seamless integration betwen the two.