Skip to content
Snippets Groups Projects
Verified Commit 93370f41 authored by Louis's avatar Louis :fire:
Browse files

Copy Ver

parents
No related branches found
No related tags found
No related merge requests found
Showing
with 133 additions and 0 deletions
assets/main_menu/logo.png

208 KiB

assets/main_menu/panel1.png

34.4 KiB

assets/panel.png

1.19 KiB

#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);
}
This diff is collapsed.
{
"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
assets/roboto.kttf-cached.png

246 KiB

assets/roboto.png

95.9 KiB

File added
assets/texture_atlas.png

10.1 KiB

book
[book]
authors = ["StarToaster"]
language = "en"
multilingual = false
src = "src"
title = "Kayak UI"
# 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
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
# 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.
# 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.
This diff is collapsed.
This diff is collapsed.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment