💭 Thoughts and Feedback

[zicklag]

Hey there, I'm just looking into Raui as a possible UI solution for my game framework and I figured I'd share my thoughts on it as I looked around. 🙂

My first thought is that the syntax for the widget units are a little confusing. I feel like the use of the {{{ is something that doesn't stick out to me as being an intentional way to create a different meaning than a single {. Like I felt the need to go look at the example code to make sure that that was indeed what distinguished a widget unit from a normal widget.

Maybe using a different macro name like widget_unit!?

Depending on how long I stick with Raui you'll probalby be getting more feedback from me, but that's it for now. 👍 It's looking pretty neat so far!

[zicklag]

My next bit of feedback: the widget macros are really nicely integrated with the IDE through Rust Analyzer!

I was able to rename my widgets or ctrl-click the names to jump between widgets! That was pretty surprising and very convenient.

[zicklag]

In the README you have:

Props feature starts to look more like a micro ECS - make use of that and make custom allocator for them that would optimize frequent props creation/cloning.

I'm considering integrated this with Bevy which actually uses an ECS which makes me wonder whether or not we could make a prop storage interface trait of some sort that could be used to actually store and access the props. Not sure if this actually makes any sense or not because I haven't gotten deep enough into the design or how it would interact with an external ECS yet.

[PsichiX]

ok, about the ECS part: i have mixed feelings about it. when i proposed that it wasn't exactly about putting data inside actual ECS (which would make it a dumb idea bc users would use RAUI with other ECS crates and that would be just a mess), it was more about design ideas around efficient storage and data access architecture, basically making an allocator for props/states to keep stuff in memory as linear as possible. Right now if you don't change state very often then you won't get much fragmentation, and props are built and immediately destroyed whenever processing pipeline runs (which means on every time when you send message to UI or state/animation changes) so i'm less concerned about props high memory fragmentation, but still i would like to at least try to be able to estimate the size of its memory and just allocate linear chunk of memory for them, use them and release memory. states could benefit from columnar storage, but this has to be tested and benchmarked how much speed it i could actually gain.
on the other hand ppl might want to store their data in their ECS, but i've covered this - for exactly that case i've made DataBinding type that allows you to access externally stored data inside RAUI components. you keep your data wrapped in DataBinding and you can keep it on ECS side and just tell RAUI to bind it with the application, whenever you change the data inside the binding, it notifies application and it renders UI with new data from DataBinding. I'm actually preparing a demo that shows this technique of using external data :D

[zicklag]

just allocate linear chunk of memory for them, use them and release memory

Gotcha, that makes sense.

on the other hand ppl might want to store their data in their ECS, but i've covered this - for exactly that case i've made DataBinding type that allows you to access externally stored data inside RAUI components. you keep your data wrapped in DataBinding and you can keep it on ECS side and just tell RAUI to bind it with the application, whenever you change the data inside the binding, it notifies application and it renders UI with new data from DataBinding. I'm actually preparing a demo that shows this technique of using external data :D

That sounds great!

[PsichiX]

also you might want to bring up one problem tho: ppl would like to build a system that uses data from queries on components.
in that case i have a potential solution: you keep your data binding in resource, then you transform queries into data that you apply to data binding and RAUI uses that transformed data to render stuff. this one would be covered in the demo i'm making too :D

[zicklag]

Using a resource sounds reasonable.

Depending on the game engine or ECS, whoever is creating the integration with RAUI might be able to automate the process of creating and syncing the resource for you so that it felt automatic, as well. Though I'd have to try it before I found out whether that actually would work, I think.

[PsichiX]

great, when you will be ready to start playing with it, we could actually make a separate branch where we could both iterate on a possibly best and "bevy-native" way of combining RAUI with bevy until we get to the point of no friction (or to prove both can't work together if that's gonna be the case)

[PsichiX]

oh boy, today i've found out that this repository does have discussion board :O
i promise read and reply tomorrow :D