Why drop Rhai?
Rhai has been serving as a fully functional configuration language of ewwii for more than a year now. During this time, it had grown a lot. I created features, libraries, transpilers, etc. focusing on rhai. So why drop it all of a sudden for a new language that has way less built-in features, you ask?
To understand, lets go back to the initial days of ewwii. I had just started this project with one single goal—make eww easier. But rhai isn’t the type of language that exactly is “easy” for this purpose. It was built the way it is for scripting purposes. Never for making UI components. And trying to make the language behave like a configuration language simply increased the complexity.
And on top of this, ewwii had to experience the constraints of rhai.
- It had terrible error reporting
- Module system was messy
- It had a verbose syntax
- Scope doesn’t propagate
And even if we ignore all these issues, it was hard to make it work because there needed to be done a lot of preprocessing of the configuration done before passing it to rhai.
To solve all these issues, under the hood, ewwii had to do manual string manipulation as preprocessing, custom module system implementation, and manual AST walking to extract all the information that we can find to then compare against a list of known situations for “kind of good” error reporting. And even after all these processing, the user experience barely gets better.
Because of all these concerns, ewwii desperately needed a new configuration language. One that is actually built for configuration, has scripting support, and is kinda nice for UI declaration. There existed none in the rust ecosystem. And outside the rust ecosystem, you can find languages like HCL, Jsonnet, KCL, etc. But I managed to find flaws in them too. The closest I got to what I needed was HCL. But it lacked the extensive “scripting” that I needed.
So I had to create my own, general purpose language named NBCL which is an abbreviation of Node-Based Configuration Language. I made sure to prioritize good error reporting, module resolver, speed, and most importantly, simplicity.
Basics of Nbcl
In Nbcl, the most basic thing is the configuration. Everything else lays above it. And you configure in a node-like system. You can read about the nodes in the nbcl documentation:
https://nbcl-lang.github.io/docs/language-guide/nodes.html
Its only about a two minute read. And that is all that you need to know to start configuring in Nbcl! The scripting aspect of the language is purely optional to get started.
Configuration
Now that you know how nodes work, you can start configuring in nbcl. There are three things to learn before you can confidently build widgets in ewwii.
- Window definition
- Poll/Listen variable difinition and usage
- Widget definition & properties
Window Definition
https://ewwii-sh.github.io/docs/config_and_syntax/getting_started
Window "bar" { geometry = { width = "100px" height = "30px" anchor = "top center" } exclusive = true
Label { text = "Glorious example!" }}Poll/Listen Variables
https://ewwii-sh.github.io/docs/config_and_syntax/variables
Window "bar" { geometry = { width = "100px" height = "30px" anchor = "top center" } exclusive = true
Label { text = global("time").mutate("Glorious time: {self}") }}
Poll "time" { cmd = "date '+%H:%M:%S'" interval = "1s"}Widget Definition & Properties
https://ewwii-sh.github.io/docs/widgets/props
component ShowWidgets () { Box { Button { label = "Click me!" } Label { text = "Don't click that button" } Eventbox { onclick = "notify-send 'Why did you click me?'" }
# More widgets can be added like so }}
Window "bar" { geometry = { width = "100px" height = "30px" anchor = "top center" } exclusive = true
ShowWidgets {}}Regarding Libraries
Nbcl is newly part of ewwii and lacks all the libraries that were custom built into rhai. Those libraries are yet to be ported to nbcl and this release doesn’t include them. If your configuration heavily relies on libraries like std::command, api::linux, etc. Then it would be better to continue using ewwii v0.6.0 until v0.8.0 releases as it will bundle all the missing features in nbcl.
Conclusion
The migration to nbcl helped in further simplifying the codebase. With this change, ewwii will have more room for growth as it is not limited by the constraints of a scripting language and will be able to give the users a more plesant configuration experience.