{"id":26038884,"url":"https://github.com/raui-labs/raui","last_synced_at":"2025-05-14T16:12:41.881Z","repository":{"id":46118539,"uuid":"104329375","full_name":"RAUI-labs/raui","owner":"RAUI-labs","description":"Rust implementation of Renderer Agnostic User Interface","archived":false,"fork":false,"pushed_at":"2025-03-23T16:15:49.000Z","size":16751,"stargazers_count":406,"open_issues_count":10,"forks_count":9,"subscribers_count":7,"default_branch":"master","last_synced_at":"2025-04-04T13:21:27.228Z","etag":null,"topics":["declarative-ui","gui","raui","rust","ui"],"latest_commit_sha":null,"homepage":"https://raui-labs.github.io/raui/","language":"Rust","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/RAUI-labs.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2017-09-21T09:38:47.000Z","updated_at":"2025-04-03T07:13:54.000Z","dependencies_parsed_at":"2023-10-11T02:02:59.934Z","dependency_job_id":"3df24ce1-3919-45fa-9e95-2c71755000db","html_url":"https://github.com/RAUI-labs/raui","commit_stats":{"total_commits":157,"total_committers":3,"mean_commits":"52.333333333333336","dds":"0.35031847133757965","last_synced_commit":"c5165c2ec1ee494558e6963e6d3ba36cf2c859b1"},"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/RAUI-labs%2Fraui","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/RAUI-labs%2Fraui/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/RAUI-labs%2Fraui/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/RAUI-labs%2Fraui/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/RAUI-labs","download_url":"https://codeload.github.com/RAUI-labs/raui/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248465314,"owners_count":21108244,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["declarative-ui","gui","raui","rust","ui"],"created_at":"2025-03-07T10:38:11.440Z","updated_at":"2025-05-14T16:12:41.873Z","avatar_url":"https://github.com/RAUI-labs.png","language":"Rust","funding_links":[],"categories":[],"sub_categories":[],"readme":"# RAUI [![Crates.io](https://img.shields.io/crates/v/raui.svg)](https://crates.io/crates/raui)[![Docs.rs](https://docs.rs/raui/badge.svg)](https://docs.rs/raui)\n\n## About\n\nRAUI is a renderer agnostic UI system that is heavily inspired by **React**'s declarative UI\ncomposition and the **Unreal Engine Slate** widget components system.\n\n\u003e 🗣 **Pronunciation:** RAUI is pronounced like **\"ra\"** ( the Egyptian god ) + **\"oui\"**\n\u003e (french for \"yes\" ) — [Audio Example][pronounciation].\n\n[pronounciation]: https://itinerarium.github.io/phoneme-synthesis/?w=/%27rawi/\n\nThe main idea behind RAUI architecture is to treat UI as another data source that you transform\ninto your target renderable data format used by your rendering engine of choice.\n\n## Architecture\n\n### [`Application`]\n\n[`Application`] is the central point of user interest. It performs whole UI processing logic.\nThere you apply widget tree that wil be processed, send messages from host application to\nwidgets and receive signals sent from widgets to host application.\n\n\n### Widgets\n\nWidgets are divided into three categories:\n- **[`WidgetNode`]** - used as source UI trees (variant that can be either a component, unit or\n  none)\n\n\n- **[`WidgetComponent`]** - you can think of them as Virtual DOM nodes, they store:\n  - pointer to _component function_ (that process their data)\n  - unique _key_ (that is a part of widget ID and will be used to tell the system if it should\n    carry its _state_ to next processing run)\n  - boxed cloneable _properties_ data\n  - _listed slots_ (simply: widget children)\n  - _named slots_ (similar to listed slots: widget children, but these ones have names assigned\n    to them, so you can access them by name instead of by index)\n- **[`WidgetUnit`]** - an atomic element that renderers use to convert into target renderable\n  data format for rendering engine of choice.\n\n### Component Function\n\nComponent functions are static functions that transforms input data (properties, state or\nneither of them) into output widget tree (usually used to simply wrap another components tree\nunder one simple component, where at some point the simplest components returns final\n_[`WidgetUnit`]'s_). They work together as a chain of transforms - root component applies some\nproperties into children components using data from its own properties or state.\n\n#### States\n\nThis may bring up a question: _**\"If i use only functions and no objects to tell how to\nvisualize UI, how do i keep some data between each render run?\"**_. For that you use _states_.\nState is a data that is stored between each processing calls as long as given widget is alive\n(that means: as long as widget id stays the same between two processing calls, to make sure your\nwidget stays the same, you use keys - if no key is assigned, system will generate one for your\nwidget but that will make it possible to die at any time if for example number of widget\nchildren changes in your common parent, your widget will change its id when key wasn't\nassigned). Some additional notes: While you use _properties_ to send information down the tree\nand _states_ to store widget data between processing cals, you can communicate with another\nwidgets and host application using messages and signals! More than that, you can use hooks to\nlisten for widget life cycle and perform actions there. It's worth noting that state uses\n_properties_ to hold its data, so by that you can for example attach multiple hooks that each of\nthem uses different data type as widget state, this opens the doors to be very creative when\ncombining different hooks that operate on the same widget.\n\n### Hooks\n\nHooks are used to put common widget logic into separate functions that can be chained in widgets\nand another hooks (you can build a reusable dependency chain of logic with that). Usually it is\nused to listen for life cycle events such as mount, change and unmount, additionally you can\nchain hooks to be processed sequentially in order they are chained in widgets and other hooks.\n\nWhat happens under the hood:\n- Application calls `button` on a node\n    - `button` calls `use_button` hook\n        - `use_button` calls `use_empty` hook\n    - `use_button` logic is executed\n- `button` logic is executed\n\n### Layouting\n\nRAUI exposes the [`Application::layout()`][core::application::Application::layout] API to allow\nuse of virtual-to-real coords mapping and custom layout engines to perform widget tree\npositioning data, which is later used by custom UI renderers to specify boxes where given\nwidgets should be placed. Every call to perform layouting will store a layout data inside\nApplication, you can always access that data at any time. There is a [`DefaultLayoutEngine`]\nthat does this in a generic way. If you find some part of its pipeline working different than\nwhat you've expected, feel free to create your custom layout engine!\n\n### Interactivity\n\nRAUI allows you to ease and automate interactions with UI by use of Interactions Engine - this\nis just a struct that implements [`perform_interactions`] method with reference to Application,\nand all you should do there is to send user input related messages to widgets. There is\n[`DefaultInteractionsEngine`] that covers widget navigation, button and input field - actions\nsent from input devices such as mouse (or any single pointer), keyboard and gamepad. When it\ncomes to UI navigation you can send raw [`NavSignal`] messages to the default interactions\nengine and despite being able to select/unselect widgets at will, you have typical navigation\nactions available: up, down, left, right, previous tab/screen, next tab/screen, also being able\nto focus text inputs and send text input changes to focused input widget. All interactive widget\ncomponents that are provided by RAUI handle all [`NavSignal`] actions in their hooks, so all\nuser has to do is to just activate navigation features for them (using [`NavItemActive`] unit\nprops). RAUI integrations that want to just use use default interactions engine should make use\nof this struct composed in them and call its [`interact`] method with information about what\ninput change was made. There is an example of that feature covered in RAUI App crate\n(`AppInteractionsEngine` struct).\n\n**NOTE: Interactions engines should use layout for pointer events so make sure that you rebuild\nlayout before you perform interactions!**\n\n[`Application`]: core::application::Application\n[`WidgetNode`]: core::widget::node::WidgetNode\n[`WidgetComponent`]: core::widget::component::WidgetComponent\n[`WidgetUnit`]: core::widget::unit::WidgetUnit\n[`DefaultLayoutEngine`]: core::layout::default_layout_engine::DefaultLayoutEngine\n[`NavSignal`]: core::widget::component::interactive::navigation::NavSignal\n[`NavItemActive`]: core::widget::component::interactive::navigation::NavItemActive\n[`perform_interactions`]: core::interactive::InteractionsEngine::perform_interactions\n[`interact`]:\ncore::interactive::default_interactions_engine::DefaultInteractionsEngine::interact\n[`DefaultInteractionsEngine`]:\ncore::interactive::default_interactions_engine::DefaultInteractionsEngine\n\n\u003c!-- Docs links from the lib.rs doc string --\u003e\n[`Application`]: https://docs.rs/raui/latest/raui/core/application/struct.Application.html\n[`WidgetNode`]: https://docs.rs/raui/latest/raui/core/widget/node/enum.WidgetNode.html\n[`WidgetComponent`]: https://docs.rs/raui/latest/raui/core/widget/component/struct.WidgetComponent.html\n[`WidgetUnit`]: https://docs.rs/raui/latest/raui/core/widget/unit/enum.WidgetUnit.html\n[`DefaultLayoutEngine`]: https://docs.rs/raui/latest/raui/core/layout/default_layout_engine/struct.DefaultLayoutEngine.html\n[`NavSignal`]: https://docs.rs/raui/latest/raui/core/widget/component/interactive/navigation/enum.NavSignal.html\n[`NavItemActive`]: https://docs.rs/raui/latest/raui/core/widget/component/interactive/navigation/struct.NavItemActive.html\n[`perform_interactions`]: https://docs.rs/raui/latest/raui/core/interactive/trait.InteractionsEngine.html#tymethod.perform_interactions\n[`interact`]: https://docs.rs/raui/latest/raui/interactive/struct.DefaultInteractionsEngine.html#method.interact\n[`DefaultInteractionsEngine`]: https://docs.rs/raui/latest/raui/interactive/struct.DefaultInteractionsEngine.html\n\n## Media\n- [`RAUI + Spitfire In-Game`](https://github.com/RAUI-labs/raui/tree/master/demos/in-game)\n  An example of an In-Game integration of RAUI with custom Material theme, using Spitfire as a renderer.\n\n  ![RAUI + Spitfire In-Game](https://github.com/RAUI-labs/raui/blob/master/media/raui-in-game-material-ui.gif?raw=true)\n\n- [`RAUI Todo App`](https://github.com/RAUI-labs/raui/tree/master/demos/todo-app)\n  An example of TODO app with dark theme Material component library.\n\n  ![RAUI Todo App](https://github.com/RAUI-labs/raui/blob/master/media/raui-todo-app-material-ui.gif?raw=true)\n\n## Contribute\nAny contribution that improves quality of the RAUI toolset is highly appreciated.\n- If you have a feature request, create an Issue post and explain the goal of the feature along with the reason why it is needed and its pros and cons.\n- Whenever you would like to create na PR, please create your feature branch from `next` branch so when it gets approved it can be simply merged using GitHub merge button\n- All changes are staged into `next` branch and new versions are made out of its commits, master is considered stable/release branch.\n- Changes should pass tests, you run tests with: `cargo test --all --features all`.\n- This readme file is generated from the `lib.rs` documentation and can be re-generated by using [`cargo readme`][cargo_readme].\n\n[cargo_readme]: https://github.com/livioribeiro/cargo-readme\n\n## Milestones\nRAUI is still in early development phase, so prepare for these changes until v1.0:\n- [ ] Integrate RAUI into one public open source Rust game.\n- [ ] Write documentation.\n- [ ] Write MD book about how to use RAUI properly and make UI efficient.\n- [ ] Implement VDOM diffing algorithm for tree rebuilding optimizations.\n- [ ] Find a solution (or make it a feature) for moving from trait objects data into strongly typed data for properties and states.\n\nThings that now are done:\n- [x] Add suport for layouting.\n- [x] Add suport for interactions (user input).\n- [x] Create renderer for GGEZ game framework.\n- [x] Create basic user components.\n- [x] Create basic Hello World example application.\n- [x] Decouple shared props from props (don't merge them, put shared props in context).\n- [x] Create TODO app as an example.\n- [x] Create In-Game app as an example.\n- [x] Create renderer for Oxygengine game engine.\n- [x] Add complex navigation system.\n- [x] Create scroll box widget.\n- [x] Add \"immediate mode UI\" builder to give alternative to macros-based declarative mode UI building (with zero overhead, it is an equivalent to declarative macros used by default, immediate mode and declarative mode widgets can talk to each other without a hassle).\n- [x] Add data binding property type to easily mutate data from outside of the application.\n- [x] Create tesselation renderer that produces Vertex + Index + Batch buffers ready for mesh renderers.\n- [x] Move from `widget_component!` and `widget_hook!` macro rules to `pre_hooks` and `post_hooks` function attributes.\n- [x] Add derive `PropsData` and `MessageData` procedural macros to gradually replace the need to call `implement_props_data!` and `implement_message_data!` macros.\n- [x] Add support for portals - an easy way to \"teleport\" sub-tree into another tree node (useful for modals and drag \u0026 drop).\n- [x] Add support for View-Model for sharing data between host app and UI.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fraui-labs%2Fraui","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fraui-labs%2Fraui","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fraui-labs%2Fraui/lists"}