Roadmap

[nicopap]

Planned features:

1. An import system where you can use templates defined in other .chirp files
2. A predefined widget library you can tap from for your own uses.
3. dynamic-query-based components, so that it's possible to declaratively define dynamic lists based on queries.
4. A pre-processed file format. For loading scenes without having to parse .chirp files nor interpreting them.
5. More layout rules.
6. Better error messages, recovering parsers.
7. Bidirectionality. So that it's possible to save back into .chirp files edited scenes. It should preserve comments, whitespaces etc.
8. UI visual editor.

Import system

You can define a template in file1.chirp and use it in file2.chirp.

Suppose your assets directory is as follow:

tree assets/
assets/
├── components
│   ├── widgets.chirp
│   └── icons.chirp
└── menus
    ├── main.chirp
    ├── pause.chirp
    └── settings.chirp

In main.chirp I want to import a button template defined in widgets.chirp.

Here is the syntax I considered:

use button in "components/widgets.chirp"
use components/widgets/button
use components::widgets::button
use "components/widgets.chirp" {button}
use "components/widgets.chirp" button
use components/widgets.chirp button
use components/widgets.chirp (button)

I would like the file path to be explicitly declared in the import statement, so that it's obvious from where the template is.

The idea is to also be able to import several templates from the same file at the same time:

use {button slider tab} in "components/widgets.chirp"
use components/widgets/{button slider tab}
use components::widgets::{button, slider, tab}
use "components/widgets.chirp" {button slider tab}
use components/widgets.chirp (button slider tab)

I am settling on use components/widgets.chirp (button slider tab) (mandatory parenthesis, even when a single symbol is imported) with the option of quoting the file path (if it has spaces or special symbols in it).

• Chirp use statement #73

Widget library

The idea is to use the embedded asset source (see bevyengine/bevy#9885), one would be able to import from it in any .chirp file using the "embedded://widgets.chirp" path.

It would be a collection of templates (just like user code) with common components such as buttons, text input or sliders.

• Text Input #107
• Add a widget library #48

Dynamic query based components

For dynamic lists with a variable amount of items, we need some iteration constructs, we also need a way to access query items from the .chirp file format. This requires dynamic queries.

The idea is to add a new "statement" with the following parameters:

1. A Query specification (either monkeying the Rust syntax or using a different one (I have a strong distaste for the rust type syntax))
2. A set of bindings, so that the query items bind with variables accessible in the nested scope
3. A single "statement". The statement acts like template, and for each query item, one instante of the template will be spawned.

Right now, I'm thinking it would look as follow:

// <> instead of () could work too
for (foo, bar) in Query((Foo, Bar), With(Baz)) {
    FooBarItem(method(foo))
}

There is one problem with this syntax. I really want to keep the language consistent. In that individual statements corresponds to one entity + as many children as you care.
But at the same time, I feel like it's fine to break this expectation with for loops

• chirp templates: for statement #94

Pre-processed file format

If I make the ParseDsl DSLs struct serializable, when loading a scene, cuicui_chirp can skip parsing a .chirp file. Which can get fairly costly.

cuicui_chirp could simply save the ParseDsl for each entity in the hierarchy and store them in a file. Then, when loading, it would just deserialize into the ParseDsl, and call DslBundle::insert. Done. This seems very easy, and the benefits are many.

• Add serialization of built-up DSLs #109
• Minimize bundle spawning in DSLs #67

More layout rules

cuicui_layout currently makes some things difficult or impossible. I want to make it more powerful. Notably, I want the ability to nest arbitrary Roots inside a given layout tree. This would allow a lot of flexibility, notably clipped layouts such as scrollable areas. I'd also like to add aspect-ratio-preserving rules.

• LayoutDsl::root is broken #101
• Root should support Rule::Children #100
• More Rules. #97
• Better image aspect ratio handling #79

Better error messages

I already did some work in this direction in #106 but I dropped work on it, now that I have much more interesting features I can implement with Asset V2.

Good error messages is what attract people to rust, if I want to attract rust users, I should ourselves provide exceptional error messages.

• More resilient parser for better error messages #103
• Better layout errors with a 2nd pass #98
• Proivde a way for users to give span & help messages #90

Save .chirp files

Ideally, changes enacted in an editor can be saved back into .chirp files. Right now, .chirp files are oriented toward manual text file authoring. But like https://enso.org/, why not have both a "visual" (ie: deserialized in-bevy format) and "textual" representations.

• Write a tool to load & edit layout chirp files #10

UI editor

An editor to demonstrate how powerful cuicui_chirp would help get us traction. Also placing us beyond every other scene file implementations.

• Add a "playground" example demonstrating functionalities #44
• Write a tool to load & edit layout chirp files #10