oh yeah! when i found that it's a trait and i can just create my own, i fell in love with it! i love how flexible it can be

one thing that may be confusing about it is that it's not clear that i need to add the
system_state_pipe_into_manager::<MyState> system. i only learned that by looking at how hover is implemented

oooh so that's what you mean by intro and outro! yeah, that does need a special thing. i really like that idea btw

i'm still new to lunex (less than 10 days) so it's hard to speak with any certainty about design choices :D
but i'll be back with any ideas i have as i use it more

thank you so much, by the way. i'm learning a lot from reading the source <3

thinking about this some more. i only have half-baked thoughts 😔

what do you think about storing the weights of states in the UiLayout, UiColor, (etc?) components? and let the user have that level of control directly?

(am i missing something here?)
i think using types is currently not doing us any favors, cause all we care about (and use) in a type that implements UiStateTrait is the value method. and we have to edit this value from some system.

also thinking about a type which keeps a current value (of the weight) and an associated movement (an animation of the weight)

in the lunex systems we access the values, do our layouting (would that be a problem for balancing?) and we animate them based on whatever animation they have

enum Movement {
    GlideTo(f32, f32), // (target, speed) when `value` reaches target, we remove this movement
    GlideToCurved(f32, f32, fn(f32) -> f32),
    Delay(Duration), // when duration is zero we remove it
    ...
}

struct Animated {
    value: f32,
    movement: Vec<Movement>,
}

maybe a From<f32> so Animated from a float would just have that value and an empty movements vec

and so the user can query the layout, set the weight of a state directly, or animate it in some way. no need for types, systems, or pipe_into_manager

and maybe the ready-to-use states that come with lunex can be some utility observers?

i'm probably missing obvious flaws, so don't hold back in your feedback! if/when we find something we all like, i'll be happy to make it happen (or help in any way)

edit: okay, yeah, maybe not in UiLayout/UiColor, cause then we'd have separate weights. maybe we do this in UiState, but just make it a HashMap<KEY, Animated> ?

// idk what keys should be
UiState::new(vec![
    ("base", Animated::from(1.0)),
    ("hover", Animated::from(0.0)),
]),
UiLayout::new(vec![
    ("base", UiLayout::window().full()),
    ("hover", UiLayout::window().x(Rl(10.0)).full())
]),

Just a quick note that this is starting to look like a full animation library.

You should check out this video: https://www.youtube.com/watch?v=WTUafAwrunE
It's a knowledge goldmine.

Anyway, one common thing in animation sequences is that not all properties are animated at once. Some are maybe delayed and such. But we here are applying all transitions at once to everything. If we are really pondering and brainstorming different ideas, maybe we could try to do some experiments. I have one such idea:

Animation sequence as list of closures on UiLayout

What if animation sequence would be a vector of closures modifying the UiLayout properties?
They would be defined as:

fn<T: UiLayoutType>(layout: T) -> T

Which would be inside: (idea from the linked video)

struct Command <T: UiLayoutType> {
    change: fn(layout: T) -> T,
    duration: f32,
}

And animation sequence would be:

Vec<Command<T>>

And when an animation is triggered, it would go over the list of closures, apply them in order and interpolate between before/after versions of passed UiLayout. Ideal would be to have this run for each field, but idk how performant that would be. Just an idea though. But the main point is that closures are the most powerful way to give user the control over the animation.

hmmm i did something messy (in the pr) but it seems to work (there's an example, you can pull locally and try it)
but i really like how you're thinking about this. i need to meditate on it :3

i did relative layout https://github.com/tomara-x/bevy_lunex/pull/2/files
(seems to work alright)

UiLayout::new(vec![
    ("base", UiLayout::window().pos(Rl(25.)).size(Rl(25.)).anchor(Anchor::TopLeft).into()),
    ("hover", UiLayout::relative("base").size(Rl(25.)).into()), // add a Rl(25) to the size of base
]),

and i'm moving base manually from a system and you can see hover is following :)

and if you don't hurry and gimme a review, i'll race you to merging depth into the layout too! jk i know you're probably busy af