Brick library exceeded my expectations. #426
Closed
amano-kenji
started this conversation in
General
Replies: 1 comment
-
Wow, thanks for this feedback - I'm so glad to hear that you had a good experience using Brick! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I always wanted to do UI programming, but I was horrified by Gtk and Qt. Weeks ago, I needed to make a program with a UI. Brick seemed like a good way.
Before I read brick user guide, I thought it was perhaps going to be good. After I read brick user guide, my mind was blown. After I designed a brick widget, it expanded my mind.
I learned brick because UI libraries for other languages seemed to force programmers to deal with too much low-level stuff.
Gtk and Qt have awkward and complex APIs. Gtk and Qt also break backward compatibility often. Monomer seems promising because it is an OpenGL GUI library written from scratch in haskell, but it doesn't support input method engine. If I don't need to support input method engine, I may consider monomer in the future. But, brick is still good enough if you don't need to display images.
Brick exposes useful primitives, yet it manages to hide low-level stuff from users.
It took time to get used to stateless rendering, but once I wrapped my mind around it, I was free to render without worrying about mutable states.
There is a GUI paradigm called functional reactive programming. Unfortunately, it is not great for interactive UIs that involve bidirectional data flow. Modeling bidirectional UI interactions as pure functions is awkward. Pure functions are great for unidirectional data flow like network packets and animations.
I guess using reactive values from https://github.com/keera-studios/keera-hails with brick will allow anyone to easily make spreadsheet because spreadsheet cells are reactive values that react to values of other cells.
Beta Was this translation helpful? Give feedback.
All reactions