Copy Ver

assets/rainbow_shader.wgsl

+#import kayak_ui::bindings::globals
+#import kayak_ui::sample_quad::sample_quad
+#import kayak_ui::vertex_output::VertexOutput
+
+fn hsv2rgb(c: vec3<f32>) -> vec3<f32>
+{
+    let K = vec4(1.0, 2.0 / 3.0, 1.0 / 3.0, 3.0);
+    let p = abs(fract(c.xxx + K.xyz) * 6.0 - K.www);
+    return c.z * mix(K.xxx, clamp(p - K.xxx, vec3(0.0), vec3(1.0)), c.y);
+}
+
+@fragment
+fn fragment(in: VertexOutput) -> @location(0) vec4<f32> {
+    var output_color = sample_quad(in);
+    let hsv = vec3(abs(sin(globals.time)), 1.0, 1.0);
+    return vec4(hsv2rgb(hsv), output_color.a);
+}

assets/roboto.kttf

+{
+    "file": "roboto.ttf",
+    "char_range_start": "0x20",
+    "char_range_end": "0x7f",
+    "offset_x": 0.0,
+    "offset_y": 25.0,
+}
\ No newline at end of file

book/.gitignore

+book

book/book.toml

+[book]
+authors = ["StarToaster"]
+language = "en"
+multilingual = false
+src = "src"
+title = "Kayak UI"

book/src/SUMMARY.md

+# Kayak UI
+
+- [Introduction](./introduction.md)
+- [Chapter 1 - Installing and hello world!](./chapter_1.md)
+- [Chapter 2 - Understanding flow](./chapter_2.md)
+- [Chapter 3 - Creating custom widgets!](./chapter_3.md)
+- [Chapter 4 - State](./chapter_4.md)
+- [Chapter 5 - Context](./chapter_5.md)
+- [Chapter 6 - Fonts](./chapter_6.md)
+- [Chapter 7 - Widget Update Systems(Diffing)](./chapter_7.md)
+- [Chapter 8 - Prebuilt Widgets](./chapter_8.md)
+- [Chapter 9 - Practical Usage](./chapter_9.md)
\ No newline at end of file

book/src/chapter_4.md

+# Chapter 4 - State
+State is data that is directly associated with a particular widget. State persists during re-renders, but will be destroyed when an widget is despawned.
+
+State can be created in Kayak easily, here is an example:
+```rust
+#[derive(Component, Default, PartialEq, Clone)]
+struct CurrentCountState {
+    foo: u32,
+}
+
+// During a widget's render function
+let state_entity = widget_context.use_state(
+    // Bevy commands
+    &mut commands,
+    // The widget entity.
+    entity,
+    // The default starting values for the state.
+    CurrentCountState::default()
+);
+
+// State can be queried like any entity.
+// This can be done via bevy query iteration or via lookup using the state_entity
+if let Ok(state) = state_query.get(state_entity) {
+    dbg!(state.foo);
+}
+
+fn my_bevy_system(state_query: Query<&CurrentCountState>) {
+    for state in state_query.iter() {
+        dbg!(state.foo);
+    }
+}
+```
+
+When an entity is despawned the state associated with that entity is also despawned.
+
+## Update/Diffing system
+By default Kayak provides a system for diffing widgets. This system is called: `widget_update` and can be attached to any widget via the root kayak context.
+
+`widget_update` takes two generic parameters called: `Props` and `State`. Both of these types expect to derive: `Component`, `PartialEq`, and `Clone`. Currently only one state type can be defined which can be an issue as widgets might have more than one piece of state. For now it's advised to group state by component type, however if a user desires they can implement a custom widget update system which manually checks more pieces of state. This is however considered to be more advanced usage and may not be as well documented.
+

book/src/chapter_5.md

+# Chapter 5 - Context
+Context in Kayak UI allows users to pass data through the widget tree without having to pass data between each widget at every level in the tree.
+
+Typically in Kayak the data is passed top-down or parent to child via "props", but this can be cumbersome when dealing with complex widget trees. Context provides a way to share values from a parent widget down to children without the need to explicitly pass that data through every level of the tree.
+
+## When to use context?
+Context can be great for sharing "global" data. This might be something as simple as a user or potentially even more complex data. In the [tabs example](../../examples/tabs/tabs.rs) we can see how context is used to pass shared tab state to the buttons and the button content.
+
+
+## How to use context?
+Context starts by creating a context entity that is associated with a piece of data and it's parent widget. This looks like:
+```rust
+// Check if the context entity already exists
+if widget_context
+    .get_context_entity::<MyContext>(entity)
+    .is_none()
+{
+    // Spawn the context entity with initial state
+    let context_entity = commands
+        .spawn(MyContext {
+            foo: 0,
+        })
+        .id();
+
+    // Let the widget context know about our custom context data.
+    widget_context.set_context_entity::<MyContext>(Some(entity), context_entity);
+}
+```
+
+Once the context has been created users can query the context in widget render systems like so:
+```rust
+fn my_child_widget_render(
+    ...
+    context_query: Query<&MyContext>,
+) {
+    // get_context_entity will jump up the tree until it finds a matching data type and entity.
+    if let Some(context_entity) = widget_context.get_context_entity::<MyContext>(entity) {
+        let context_data = context_query.get(context_entity);
+        dbg!(context_data.foo);
+    }
+}
+```
+
+## Handling diff and widget updating
+When a widget is associated with context it's important that the widget update system is aware of this. By default the `widget_update` diff system is used. This accepts types for props and state but not for context. A separate system called `widget_update_with_context` can be used which takes an optional third type for context.
+
+### Important!
+`widget_update_with_context` is only designed to work with one type of context. If you need multiple context diffing for a single widget it's advised that you use a custom widget update system.